Ihr Elenden Perversen! Haltet euch an den Standard!

[CarstenJ]

Unabhängig von dem Inhalt deiner Aussagen, macht auch der Ton die Musik.

[SideWinder]

Freie Radikale darf es auch geben. Wir sind hier im Internet und nicht bei Oma zu Besuch

MfG SideWinder

[elise]

hallo??

bücher sind teuer. in schulen gibt es nicht immer die neuesten.
ebenso finden sich in der bibliothek eine masse guter bücher, die -verdammnichnochmal- diese "gruselige" <iostream.h> einbindet.

*wetterdiewetter*

so, und nu mal im ernst: ihr seid alle erwachsen, könnt denken, nach einmaliger klärung ändert ihr einfach die zeile, wenn ihr ein älteres buch erwischt, und:

gut is

es gibt doch nichts langweiligeres, als immer wieder den gleichen mist zu bewettern.
und wenn der lehrer es nicht rafft.. wat solls, ihr wisst es besser. dafür kann er eventuell bessere algos. und das ist mehr wert.

mein gott, man kann sich auch über interessantere dinge unterhalten.

schokolade zum bleistift

[***]

"Professionelles Einsteiger Tutorial"

Professionelles Turorial, gibt es den sowas? "professionel" bedeute "beruflich", und wer beruflich was lernt nimmt meistens Untericht.

main ()
{
}

int main (void)
{
    return 0;
}

int main (int argc, char *argv[])
{
    return 0;
}

Ich bin für:

int main(){
  return 0;
}

#include <iostream.h>
#include <stdio.h>
#include <math.h>
#include <assert.h>

 // als
#include <iostream>
#include <cstdio>
#include <cmath>
#include <cassert>

Bei <iostream.h> hast du recht ist kein Standart, aber <stdio.h>, <math.h> und <assert.h> sind C++ Standart und deshalb nur aus manchen Stilansichten verwerflich (und ich bin nicht gerade Vertreter dieses Stils).

#define __MAX_TYPES_FIGHTERS 100

// als

const int MAX_TYPES_FIGHTERS = 100;

// bzw.
enum MAX_TYPES
{
    FIGHTERS = 100,
    NONE = 0
};

Von Standart her ist nur ersteres wegen den __ die für die Compilermplementierung reserviert sind verwerflich, der Rest ist standartkonform. Von Stil her würde ich Fall zwei nehmen und zwar klein geschrieben, da es kein Preprocessor Befehl ist. enum MAX_TYPES ist nicht so gut weil hier Dinge wie int a=FIGHTERS; alles anderes als eindeutig sind.
Am aller besten ist aber immer noch:

class Fighter{
public:
  static const max=100;
};

Mag sein, aber ich bin mir relativ sicher, das Du es mit const oder enum regeln würdest!

Definiere "es". Auf was Pronomen verweisen sollte aus dem Kontext klar werden, das ist ungeschriebener internationaler Sprachstandart.

Ich denk mal Du würdest es am liebsten richtig haben, als Bullshit vor der Nase zu haben, welches Du lernst.

Wenn ich versuche den Satz zu verstehen geht folgendes in meinem Kopf vor:
Warnung : Zeile 1, Wort 4 : in einem Satz wird "Du" kein geschrieben.
Fehler : Zeile 1, Wort 6 : "es" kann nicht auf ein vorher genanntes Nomen oder untergeordneten Satz bezogen werden, also ist es (bezieht sich auf "es") undefiniert.
Fehler : Zeile 1, Wort 11 : Ein Vergleich kann nicht durch "als" eingleitet werden wenn sich vorher ein Superlativ befindet. Vergleich:
Susi hat Tim lieber als Paul.
Warnung : Zeile 1, Wort 18 : Es (allgemeines "es") heist "der Bullshit" also muss du "welchen" anstatt von "welches" gebrauchen.
Warnung : Zeile 1, Wort 19 : Wiederholte Fehler werden nur einmal gemeldet.
Satzverständins : 2 Fehler, 3 Warnung daraus schließe ich, dass dieses Dialekt nicht mit dem von mir anerkannten Sprachstandart kompatibel ist.
Oder um das ein wenig deutlicher auszudrücken:
Lern schreiben bevor du eine Predigt über Standartgemässigkeit hälst.

PS: Wenn du bei mir Schreibfehler findest ist nicht so schlimm da ich ja auch nicht predige man solle sich an Standarts halten.

und ich finde, die zahlreichen abweichungen und erweiterungen die z.b. der microsoft compiler hat nicht schlecht!

Kommt darauf an was du genau meinst, aus Erfahrung finde ich es gut um alles wo M$ draufsteht einen großen Bogen zu machen.

[DrGreenthumb]

und ich finde, die zahlreichen abweichungen und erweiterungen die z.b. der microsoft compiler hat nicht schlecht!

Nenn mal einen.

Meinst du die Erweiterung CString? Oder Das Feature von for-Überlebenen Variablen?

aber <stdio.h>, <math.h> und <assert.h> sind C++ stan****

nein

[b7f7]

DrGreenthumb schrieb:

und ich finde, die zahlreichen abweichungen und erweiterungen die z.b. der microsoft compiler hat nicht schlecht!

Nenn mal einen.

Meinst du die Erweiterung CString? Oder Das Feature von for-Überlebenen Variablen?

aber <stdio.h>, <math.h> und <assert.h> sind C++ stan****

nein

compatibilitäts modus ausschalten und die variablen leben nur noch in der for schleife.
obsolete bedeutet nicht "nicht standard" konform

[nix da]

***
Neue Rechtschreibreform, man kann "Du" groß oder klein schreiben, es ist egal, außer "Ihnen" und "Sie", welche die einzigsten Anreden sind die groß geschrieben werden müssen, hat man bei "Du" die Qual der Wahl.

Standard schreibt man mit D wie Dora am Ende, nicht mit T.

Wenn Du Beruflich nur im Unterricht lernst, tust Du mir leid.

stdio.h
math.h
assert.h

ist kein ISO-C++ Standard. Das ist ANSI C Standard.

Dein persönlicher Angriff wurde ignoriert, denn Du bist mir egal.

[Gast]

@b7f7: Man kann auch die Erweiterungen an haben und die Variablen leben nur innerhalb der for-Schleife. Das ist sogar die Standardeinstellung.
Das Thema mit den Schleifen hat mit Erweiterungen nichts zu tun, das liegt daran, dass die Regelung früher anders war und die Compiler noch eine Art Kompatibilitätsmodus anbieten.

Für VC++: force conformance in for-loop scopes

[Bashar]

nix da schrieb:

stdio.h
math.h
assert.h

ist kein ISO-C++ Standard. Das ist ANSI C Standard.

§D.5 du Pfeife
'nuff said

[Gast]

DrGreenthumb schrieb:

Meinst du die Erweiterung CString? Oder Das Feature von for-Überlebenen Variablen?

Ich finde z.B.

functionName(&ClassName(ctor_args));

nicht schlecht, weil es mir auf den Sack gehen würde, dafür jedesmal eine temporäre Variable zu definieren.

CString ist keine Erweiterung zur Sprache C++ (anders als die managed Extensions), sondern eine Stringklasse wie jeder sie auch schreiben kann.

Und die Erweiterungen sind außerdem abstellbar, weswegen ich die Aufregung sowieso nicht verstehe.

[DrGreenthumb]

compatibilitäts modus ausschalten und die variablen leben nur noch in der for schleife.
obsolete bedeutet nicht "nicht standard" konform

Ach, das ist obsolete, sprich war mal überall so? Aber wenn etwas veraltet ist, nicht mehr dem heutigen Standard entspricht, ist es auch nicht mehr so ganz Standard-Konform...

Wenn das mit einem Häkchen getan ist, wieso lese ich dann immer dieses komische if-define?

Na mir auch latte. Das war nur ein ironisches Beispiel, zur Frage nach den "Erweiterungen".

[DrGreenthumb]

Optimizer schrieb:

Ich finde z.B.

functionName(&ClassName(ctor_args));

nicht schlecht, weil es mir auf den Sack gehen würde, dafür jedesmal eine temporäre Variable zu definieren.

Und dass ist auch eine Erweiterung, und nicht nur Zufall?
Die temporäre Variable muss man in Kauf nehmen, wenn man C++ schreiben will. Das ist eben eine Eigenschaft der Sprache. Wenn du die "Erweiterungen" benutzt, nenn es meinetwegen MS-C++.

CString ist keine Erweiterung zur Sprache C++ (anders als die managed Extensions), sondern eine Stringklasse wie jeder sie auch schreiben kann.

Sach an...

[Shade Of Mine]

DrGreenthumb schrieb:

Wenn das mit einem Häkchen getan ist, wieso lese ich dann immer dieses komische if-define?

Weil der VC++6 es nicht kann. Die neueren koennen den for scope richtig setzen, ist aber defaultmaessig falsch rum.

[SirLant]

Mein VC7.1 setzt den for-scope, aber richtig (default).

Man sollte sich an den Standard halten mit einem Auge auf die Funktionalität der großen Compiler,
so wäre ein "export" in einem Programm schlecht, da es so gut wie kein Compiler beherrscht.
Dagegen sind Funktionstemplates ne schöne Alternative zu Makros (wo es natürlich möglich ist).

[Printkey]

1.) Von einzig gibt es keine Steigerung, O-Ton "Meine fresse regt mich das auf ich könnte jedesmal kotzen welcher dumme scheiss deutschlehrer bringt allen das immer bei das muss ich immer lesen und bin unfähig die person einfach darauf hinzuweisen das es kein "einzigster" gibt!"

2.)
Das mit dem CKlasse ist jawohl total die Ansichtssache, uhh es kommt von MS NEIN ist nicht wahr. Ich benutze es trotzdem weil ich das übersichtlicher finde, es ist mein Standard. Andere schreiben bool bWert, oder int INTEGER oder was weiß ich, dass ist doch vollkommen jacke wie hose

[b7f7]

DrGreenthumb schrieb:

compatibilitäts modus ausschalten und die variablen leben nur noch in der for schleife.
obsolete bedeutet nicht "nicht standard" konform

Ach, das ist obsolete, sprich war mal überall so? Aber wenn etwas veraltet ist, nicht mehr dem heutigen Standard entspricht, ist es auch nicht mehr so ganz Standard-Konform...

aber es war mal gültig und deshalb nicht falsch.
[quote="DrGreenthumb"]

Wenn das mit einem Häkchen getan ist, wieso lese ich dann immer dieses komische if-define?

Na mir auch latte. Das war nur ein ironisches Beispiel, zur Frage nach den "Erweiterungen".

weil es das Häkchen gibt(auch in VS 6), aber weil mit den meisten MFC klassen das wiederum zu Konflikten mit anderen abgeschalteten erweiterungen und eben mit dem scope von Variablen gibt.

[Shade Of Mine]

Printkey schrieb:

Das mit dem CKlasse ist jawohl total die Ansichtssache, uhh es kommt von MS NEIN ist nicht wahr.

C ist der Namespace der MFC, genauso wie T der Namespace von Borland (ehemals wegen Turbo Vision) ist.

[Printkey]

aber was ist daran so schlimm das ich es für meine klassen benutze?

[Artchi]

Nichts schlimmes dran, finde ich. Wenn man es nachher portieren will, muß man natürlich eine Lösung finden. Weiß auch nicht was sich alle aufregen, auch wenn ich pers. std::string bevorzuge.

[Shade Of Mine]

Printkey schrieb:

aber was ist daran so schlimm das ich es für meine klassen benutze?

Namespace Konflikt.

Wenn ein Programmierer CWnd oder CDialog oder CString sieht, denkt er sofort an die MFC. Es sei denn er ist schon ganz verunstaltet von diesen C* sachen...

Früher gab es noch keine namespaces - da wurden prefixe verwendet. Das C kennzeichnet den Namespace der MFC, oder meinetwegen von Microsoft. Das T gehört zB Borland. wx ist der namespace von wxWindows.

Ich wette mit dir, wenn MS nicht C sondern MFC als Präfix gewählt hätte, dann hätten wir heute weit weniger C* Fans. Denn dann würde man nie auf die Idee kommen C oder MFC als Präfix zu verwenden. Denn es macht ja keinen Sinn

T ist bei Borlander genauso wie C bei MSler. Oft höre ich Argumente ala 'C steht doch für Class' - aber bei sowas schmunzle ich dann immer. Denn C steht für MFC.

Und selbst wenn wie C_* nehmen würden um uns von der MFC zu trennen, so bleibt die Frage: Was bringt es uns? Haben wir OOP nicht verstanden? Was sagt uns die schöne OOP denn? Das verhalten hängt vom Objekt ab. Und ist es nicht egal welchen Typen dieses Objekt hat? int, char, Foo? Ist alles gleich, weil das Verhalten wichtig ist.

Warum also einen Typen mit C präfixen? Das würde uns helfen zu erkennen ob dieser Typ eine Klasse, ein Interface, eine struct oder sonstwas ist.

Doch warum wollen wir das wissen?

Ist es nicht so, dass ich
Int32 i=7;
cout<<i+3;
schreiben kann und weiss, dass 10 ausgegeben wird?

Ist es denn so wichtig ob Int32 ein typedef auf int ist, oder eine Klasse? Das Verhalten zählt - mehr nicht.

Und was ist, wenn sich der Typ ändert?
Da habe ich CInt32 und aufeinmal habe ich einen nativen 32Bit integer. Natürlich verwende ich den, weil er schneller ist und er für meine Zwecke ausreicht. Normalerweise könnte ich einfach ein typedef int Int32; machen. Aber jetzt geht das ja nicht.

typedef int CInt32; wäre ein Verbrechen. Folglich muss ich den Code umschreiben.

Klar, es gibt Search&Replace. Doch was ist mit Client Code?
Angenommen wir bieten für unsere tolle Anwendung eine Plugin Schnittstelle an. Da müssen wir etwas Code offenlegen - auch wenn es nur Deklarationen sind. Aber trotzdem kommt dort CInt32 vor. Und schon können wir diese Änderung nicht mehr durchführen. OK, können schon - aber das ist doch nun wirklich hässlich, oder?

Wie wäre es mit einem anderen Beispiel: Interface und Klasse - falls du diese beiden trennst. Einmal I_* und einmal C_*

Doch wo ist die Grenze? Es ist doch nur ein kleiner Schritt zwischen einer Basisklasse mit virtuellen Methoden und einem Interface. Denn ein Interface ist ja nur ein Spezialfall so einer Klasse.

Wir könnten also durchaus unsere Basisklasse abstrakt machen wollen - was ja ansich keine grobe Designänderung ist. Doch wenn wir sie bereits C_Auto genannt haben, dann wird es doof. Denn jetzt ist sie abstrakt und somit ein Interface und kein C_Auto mehr, sondern ein I_Auto.

Und schon wieder müssen wir Search&Replace machen und schon wieder müssen wir Client Code ändern.

Ne, ne, ne - das alles sind mir zuviele Nachteile.
Und wo ist der Vorteil? Bringt es mir wirklich so viele Vorteile am Namen zu erkennen was es ist? Ich kann doch die Features meiner IDE verwenden -> einfach Mauszeiger über den Namen, oder draufklicken oder sonstwas - und schon steht "class Auto" oder "struct Auto" oder "typedef int Auto; //bloedes Beispiel" da.

Wenn man jetzt noch class und interface trennen will -> #define interface class und alles ist palletti.