proggen.org

fat-lobyte hat geschrieben:Hallo!
Ich möchte nur kurz von meinen Erfahrungen berichten.
Im neuen Standard gibt es einige Änderungen, wie man Objekte und Basisklassen initialisiert.

Wozu ist das überhaupt notwendig?

Betrachtet folgenden Code:

Code: Alles auswählen

rectangle        w (origin(), extents());
complex<double>  c (2.71828, 3.14159);
int              a[] = {1, 2, 3, ,4};
vector           v; for(int i;i<=4;++i) v.push_back(i);

Alle dieser vier Zeilen dienen der *Absicht* ein Objekt zu deklarieren und zu initialisieren. Diese sehen aber unterschiedlich aus, und bei Vektor muss man sogar Code für die initialisierung bereitstellen. Warum sage ich "Absicht"? ÜBERRASCHUNG!! Die erste Zeile, die zwar aussieht wie eine Variablendeklaration ist eine Funktionsdefinition!

fat-lobyte hat geschrieben: Und es verhindert die "Verschmälerung" (narrowing), Beispielsweise von integer und floating point datentypen:

Code: Alles auswählen

int x0= 7.3;	// ok: aber daten gehen verloren!
int x1 {7.3};	// error: narrowing

fat-lobyte hat geschrieben:Das habe ich gemacht, und siehe da: zwei Problemchen:
1) Referenzen!

Code: Alles auswählen

struct A{};

int main()
{
    A a;
    A& a_ref{a}; // BUMM!!
}

Wieso auf einmal? Tja, hier wird aus {a} erstmal ein temporäres Objekt des Typs A erstellt, und mit a initialisiert. Dieses temp. Objekt wäre dann RValue und müsste mit einer nicht konstanten Referenz verknüpft werden. Das macht keinen Sinn: was ist eine Referenz auf ein Temporäres Objekt?
Seltsame Sache ist das, aber leider ist das so, also muss man hier weiterhin a_ref() schreiben.

fat-lobyte hat geschrieben: 2) Wenn der Konstruktor eine intializer_list akzeptieren würde!
Die folgenden zwei Zeilen haben nicht den gleichen Effekt!!

Code: Alles auswählen

std::vector<int> v(100);
std::vector<int> v{100};

Wieso nicht? Nun, das betrifft zwei Konstruktoren des vector's:

Code: Alles auswählen

explicit vector(size_type n); // 1
vector(initializer_list<T>, const Allocator& = Allocator()); // 2

Die erste Zeile ruft den ersten konstruktor auf, es wird ein vektor mit 100 Elementen erstellt.
Die zweite Zeile erstellt aber ein objekt vom Typ std::initializer_list<int>, mit einem Element, nämlich 100 -> der zweite Konstruktor wird aufgerufen.

fat-lobyte hat geschrieben:Tja, das finde ich persönlich wirklich unschön aber auch damit muss ich Leben.

Xin hat geschrieben:Seit wann enthält eine Funktionsdefinition Aufrufe von anderen Funktionen/Konstruktoren?

Xin hat geschrieben:

fat-lobyte hat geschrieben: Und es verhindert die "Verschmälerung" (narrowing), Beispielsweise von integer und floating point datentypen:

Code: Alles auswählen

int x0= 7.3;	// ok: aber daten gehen verloren!
int x1 {7.3};	// error: narrowing

Das finde ich grundsätzlich gut - allerdings würde ich sie abschaffen - bzw. tue das. int x0 = 7.3 ist bei mir nicht kompilierbar.

Xin hat geschrieben:

fat-lobyte hat geschrieben:Das habe ich gemacht, und siehe da: zwei Problemchen:
1) Referenzen!

Code: Alles auswählen

struct A{};

int main()
{
    A a;
    A& a_ref{a}; // BUMM!!
}

Wieso auf einmal? Tja, hier wird aus {a} erstmal ein temporäres Objekt des Typs A erstellt, und mit a initialisiert. Dieses temp. Objekt wäre dann RValue und müsste mit einer nicht konstanten Referenz verknüpft werden. Das macht keinen Sinn: was ist eine Referenz auf ein Temporäres Objekt?
Seltsame Sache ist das, aber leider ist das so, also muss man hier weiterhin a_ref() schreiben.

Es macht in meinen Augen keinen Sinn hier ein temporäres Objekt zu erstellen. Bug oder Feature?

struct Punkt
{
    Punkt (int x, int y) : _x{x}, _y{y} {}

    int _x, _y;
};

struct Rechteck 
{
    Rechteck(const Punkt& lo, const Punkt& ru) : _lo{lo}, _ru{ru} {}
    Punkt _lo, _ru;
};

Rechteck r{Punkt{1, 2}, Punkt{3, 4}};

Xin hat geschrieben:Wie entsteht die Logik, dass bei {100} eine std::initializier_list< int > erzeugt wird?

std::vector<int> v = {1, 2, 3, 4, 5};

Xin hat geschrieben:

fat-lobyte hat geschrieben:Tja, das finde ich persönlich wirklich unschön aber auch damit muss ich Leben.

Ich interessiere mich sehr für solche Dinge - mit dem Unterschied, dass ich damit nicht leben muss. Ich muss mich aber damit beschäftigen, damit ich solche Szenarien verhindern kann.

Xin hat geschrieben:Ein Link auf diesen Thread landet bei mir im Wiki.

Xin hat geschrieben:Wir könnten uns beizeiten nochmal um Erweiterungen im C++-Tutorial unterhalten - das hier scheint mir dafür bereits hervorragend geeignet zu sein...

fat-lobyte hat geschrieben:

Xin hat geschrieben:Seit wann enthält eine Funktionsdefinition Aufrufe von anderen Funktionen/Konstruktoren?

Wenn orgin und extens typen sind, dann sieht das für den compiler so aus, als ob die Klammern "zum Spaß" dort stehen, dann kommt das mit der Funktionsdeklaration hin. Mehr info hier: http://www.informit.com/guides/content. ... seqNum=439

fat-lobyte hat geschrieben:

Xin hat geschrieben:

fat-lobyte hat geschrieben: Und es verhindert die "Verschmälerung" (narrowing), Beispielsweise von integer und floating point datentypen:

Code: Alles auswählen

int x0= 7.3;	// ok: aber daten gehen verloren!
int x1 {7.3};	// error: narrowing

Das finde ich grundsätzlich gut - allerdings würde ich sie abschaffen - bzw. tue das. int x0 = 7.3 ist bei mir nicht kompilierbar.

Das geht in C++ nicht, da man kompatibilität mit C wahren will. Außerdem weiß ich nicht ob ich das gut finden würde das ganz abzuschaffen... Jetzt hat man beide möglichkeiten, da muss man eine nicht verbieten.

fat-lobyte hat geschrieben:

Xin hat geschrieben: Es macht in meinen Augen keinen Sinn hier ein temporäres Objekt zu erstellen. Bug oder Feature?

Gut Frage. Ich tippe mal auf Feature, denn:

Code: Alles auswählen

struct Punkt
{
    Punkt (int x, int y) : _x{x}, _y{y} {}

    int _x, _y;
};

struct Rechteck 
{
    Rechteck(const Punkt& lo, const Punkt& ru) : _lo{lo}, _ru{ru} {}
    Punkt _lo, _ru;
};

Rechteck r{Punkt{1, 2}, Punkt{3, 4}};

Wäre sonst nicht möglich. Übrigens: man hätte auch Rechteck r{{1,2}, {3, 4}}; schreiben können. Ich nenne das den "Du weißt eh was ich meine"-Konstruktor

fat-lobyte hat geschrieben:

Xin hat geschrieben:Wie entsteht die Logik, dass bei {100} eine std::initializier_list< int > erzeugt wird?

Man kan in C++11 Vektoren und andere Container direkt bei ihrer deklaration initialisieren:

Code: Alles auswählen

std::vector<int> v = {1, 2, 3, 4, 5};

Macht die Sache sehr hübsch, Meinermeinung nach. Das funktioniert dann über ein temporäres Objekt des Typs std::initializer_list<int>, das dem Konstruktor von vector<> übergeben wird.

fat-lobyte hat geschrieben:Denkst du, du könntest eine Ähnlich mächtige Sprache schaffen, die keine derartigen Probleme hat? Da gibts interaktionen der einzelnen Elemente, auf die man als einzelne Person nie draufkommen würde - da braucht man viele, viele Augenpaare.

fat-lobyte hat geschrieben:

Ein Link auf diesen Thread landet bei mir im Wiki.

Ähem... <werbung>Wie wärs dann noch mit diesem Thread hier: http://www.proggen.org/forum/viewtopic. ... 2</werbung>

fat-lobyte hat geschrieben:Hm, das ist so ne Sache. Das was du "Erweiterung" nennst, betrachte ich eigentlich als ne ziemlich neue Sprache - diese kleinen "Erweiterungen" ändern einfach "wie man Dinge macht", also vorhandene Praktiken.

fat-lobyte hat geschrieben:Workarounds die man früher hatte werden Obsolet (konstruktor vs. funktionsdekl.), gewisse Dinge werden vieel einfacher (auto, range-based-for loop). Ich bin mir nicht sicher obs so viel Sinn macht, auf ein bestehendes Tutorial die neuen Features einfach drüberzustülpen.

Xin hat geschrieben:

fat-lobyte hat geschrieben:Wenn orgin und extens typen sind, dann sieht das für den compiler so aus, als ob die Klammern "zum Spaß" dort stehen, dann kommt das mit der Funktionsdeklaration hin. Mehr info hier: http://www.informit.com/guides/content. ... seqNum=439

Wenn da Klammern hinterstehen, dann nicht zum Spaß, sondern weil man den Standard-Konstruktor rufen will.

Xin hat geschrieben:Man kann auch das Spracheverhalten ändern. Erst mit Warnings, dann mit Fehlern und einem Schalter, der den Compiler in einen Kompatiblitätsmodus versetzt.

Kompatiblität ist gut, aber man sollte sich durchaus bewusst sein, dass Quellen, die vor 30 Jahren geschrieben wurden zwischenzeitlich vielleicht nochmal angepackt werden müssen.

Xin hat geschrieben:Bei mir heißt das Erwartungshaltung.

Xin hat geschrieben:Ich bin überhaupt kein Freund von temporären Objekten.

// A struct that represents a window class
	WNDCLASSEX wndclass;	
	
	/* This is a variable containing the style flags for the Window Class. */
	UINT wnd_style = CS_HREDRAW | CS_VREDRAW;
	
	
	/* These values will be handed over to the CreateWindowEx() function. */
	int start_x = CW_USEDEFAULT;
	int start_y = CW_USEDEFAULT;	
	
	

	/* Filling wndclass Structure */
	wndclass.cbSize = sizeof (WNDCLASSEX);
	wndclass.style = wnd_style;
	wndclass.lpfnWndProc = wndProc;
	wndclass.cbClsExtra = 0;
	wndclass.cbWndExtra = 0;
	wndclass.hInstance = hInstance;
	wndclass.hIcon = LoadIcon(NULL, IDI_APPLICATION);
	wndclass.hCursor = LoadCursor (NULL, IDC_ARROW);
	wndclass.hbrBackground = (HBRUSH) GetStockObject (LTGRAY_BRUSH);
	wndclass.lpszMenuName = NULL;
	wndclass.lpszClassName = szAppName;
	wndclass.hIconSm =  LoadIcon (NULL, IDI_APPLICATION);
	
	
	// register window class
	registerWndClass(&wndclass);
	
	// create a window
	create(0, 
		szAppName,
		title,
		WS_OVERLAPPEDWINDOW | WS_VISIBLE,
		start_x, start_y,
		width, height,
		NULL,
		NULL,
		hInstance,
		0);

Und den Mut, wieder ein paar Schritte zurück zu gehen, wenn man auf dem Holzweg war.

Xin hat geschrieben:Ich habe mir heute ein Buch zu C++11 bestellt. Mit etwas Glück kommt es rechtzeitig an, dass ich es im Hotel lesen kann. Da kann man ja sonst nicht viel sinnvolles tun, also optimal, um ein Buch zu lesen... wenn's rechtzeitig da ist.

fat-lobyte hat geschrieben:Hm, das ist so ne Sache. Das was du "Erweiterung" nennst, betrachte ich eigentlich als ne ziemlich neue Sprache - diese kleinen "Erweiterungen" ändern einfach "wie man Dinge macht", also vorhandene Praktiken.

Xin hat geschrieben:Das müssen wir dann Feature für Feature entscheiden.
Es ist ja auch eine zeitliche Frage: Was nutzt es ein Feature groß hervorzuheben, dass z.B. das aktuelle Visual Studio gar nicht versteht.
Da muss das Feature aus dem Tutorial heraus und als Artikel dazu: "Wenn Du einen aktuellen Compiler hast, dann siehe >>Artikel<<". Ich kann von einem interessierten Anfänger nicht verlangen, sich den aktuellen GCC selbst zu kompilieren. Der wird sich daran erinnern, dass ihm jeder gesagt hat, C++ ist zu kompliziert und das bestätigt finden.

Fakt ist, zurzeit bist Du hier der C++11-King hier und Du wolltest damals mit mir das C++-Tutorial voranbringen. Bzgl. der Deines C++-King-Titels werde ich Dir den auf kurz oder lang wieder streitig machen.

C++11 muss ins Wiki und kommt ins Wiki. Im Idealfall für's Wiki setzen wir uns zusammen hin und planen das gemeinsam.

Im C Tutorial muss ich noch drei, vier Artikel hinzufügen, und den alten Index ausmisten. Dann ist das durch und sauber.
Dann gehe ich zum C++-Tutorial und werde da die Baustelle schließen, wäre gut, wenn ich dann zumindest jemand habe, mit dem ich den Aufbau diskutieren kann. Schreiben kann ich das schon.

fat-lobyte hat geschrieben:

Xin hat geschrieben:

fat-lobyte hat geschrieben:Wenn orgin und extens typen sind, dann sieht das für den compiler so aus, als ob die Klammern "zum Spaß" dort stehen, dann kommt das mit der Funktionsdeklaration hin. Mehr info hier: http://www.informit.com/guides/content. ... seqNum=439

Wenn da Klammern hinterstehen, dann nicht zum Spaß, sondern weil man den Standard-Konstruktor rufen will.

Jetzt ok, dann sind es zwei Funktionszeiger auf Funktionen die keine Argumente nehmen und origin/extent-Objekte zurückgeben. Hast du das Problem ehrlich noch nie gehabt?

fat-lobyte hat geschrieben:

Xin hat geschrieben:Man kann auch das Spracheverhalten ändern. Erst mit Warnings, dann mit Fehlern und einem Schalter, der den Compiler in einen Kompatiblitätsmodus versetzt.

Kompatiblität ist gut, aber man sollte sich durchaus bewusst sein, dass Quellen, die vor 30 Jahren geschrieben wurden zwischenzeitlich vielleicht nochmal angepackt werden müssen.

Das sehe ich ähnlich, ewig Ballast mitzuführen ist keine gute Sache. Die Argumentation des Standardkommittees (vor allem Bjarne Stroustrup) ist, dass man "Dialektbildung" und "Zersplitterung" der Community vermeiden will, die entstehen könnte wenn man ein "veraltetes", aber dennoch verbreitetes Feature entfernt.

fat-lobyte hat geschrieben:

Xin hat geschrieben:Ich bin überhaupt kein Freund von temporären Objekten.

Ich bin ein großer Freund davon.
Hier ein bisschen Code aus der Zeit, in der mich Windows noch interessiert hat:
...

Das ist C. Hier wurden keine temporären Objekte angelegt. Nur wieso nicht?? Warum muss ich jedes futzelchen Code definieren? Warum muss ich extra Variablen am Stack anlegen, die dann sowieso gleich gefressen werden, und in anderen Objekten verschwinden? Wieso hin und her kopieren?

fat-lobyte hat geschrieben:

Und den Mut, wieder ein paar Schritte zurück zu gehen, wenn man auf dem Holzweg war.

Ein Ambitioniertes Projekt

fat-lobyte hat geschrieben:

Xin hat geschrieben:Ich habe mir heute ein Buch zu C++11 bestellt. Mit etwas Glück kommt es rechtzeitig an, dass ich es im Hotel lesen kann. Da kann man ja sonst nicht viel sinnvolles tun, also optimal, um ein Buch zu lesen... wenn's rechtzeitig da ist.

Sowas gibts schon?? Sollte man mit Büchern zu "existing Practice" nicht warten, bis die Praxis tatsächlich existiert?

fat-lobyte hat geschrieben:Andererseits: willst du wirklich Artikel schreiben, die ein Ablaufdatum haben? Ich persönlich finde das ziemlich frustrierend.

fat-lobyte hat geschrieben:Ich schreibe lieber in der Zukunft, und impliziere, dass der Leser einen Standardkonformen Compiler hat. Ich weiß nicht wie viele Leser das C++-Tutorial hat, aber die wenigen, die dabei "draufgehen" bis in ungefähr einem Jahr die Compiler nachgerüstet haben würde ich in Kauf nehmen.

fat-lobyte hat geschrieben:

Im C Tutorial muss ich noch drei, vier Artikel hinzufügen, und den alten Index ausmisten. Dann ist das durch und sauber.
Dann gehe ich zum C++-Tutorial und werde da die Baustelle schließen, wäre gut, wenn ich dann zumindest jemand habe, mit dem ich den Aufbau diskutieren kann. Schreiben kann ich das schon.

Klingt nach nem Plan.

Xin hat geschrieben:Entweder sehe ich Dein Problem nicht oder es gibt keins!?

struct B {
    B() {}
};

struct A {
    A(B b) { }    
    void myMethod() {}
};

int main()
{
    A a(B());    
    a.myMethod();
}

Xin hat geschrieben:Du legst temporäre Objekte an, um sie zu kopieren.

Xin hat geschrieben:Weil ich das Hin- und Herkopieren nicht gut finde - vor allem weil es Zeit kostet -

Xin hat geschrieben:Ich bevorzuge einen zweistufigen Aufbau von Objekten: Das Fundament des Objektes wird aufgebaut (Speicher reserviert), anschließend beschickt man die Daten.

Xin hat geschrieben:Höre ich häufiger. Üblicherweise als Umschreibung für zu aufwendig, nicht umsetzbar.

fat-lobyte hat geschrieben:Es gibt kein 'gut für alle Zeiten'. Ich habe keine Ahnung, was morgen kommt. Aber es gibt ein erreichbares "Gut" in der Gegenwart. Ich kann in der Gegenwart darauf hinweisen, was man in der Zukunft gut machen könnte. Und wenn das dann jeder macht, dann ist der Artikel veraltet.

Xin hat geschrieben:Es gibt noch keine standardkonformen C++-Compiler. Sollten Standards also nie umgesetzt werden, schreibst Du über Dinge, die in der Realität nicht vorkommen. Sogar den alten Standard unterstützt kaum einer vollständig.

Xin hat geschrieben:Machst Du bei GDB/GIT weiter?

fat-lobyte hat geschrieben:

Xin hat geschrieben:Entweder sehe ich Dein Problem nicht oder es gibt keins!?

Code: Alles auswählen

struct B {
    B() {}
};

struct A {
    A(B b) { }    
    void myMethod() {}
};

int main()
{
    A a(B());    
    a.myMethod();
}

Quizzfrage: was tut die Zeile A a(B()); ? Nach der Antwort kompiliere bitte dieses Programm.

    A a=B();
oder bei explicit:
    A a = A(B());    

fat-lobyte hat geschrieben:

Xin hat geschrieben:Du legst temporäre Objekte an, um sie zu kopieren.

Eben nicht! Das musste ich bisher, jetzt kann ich sie statt zu kopieren in das Objekt "hineinmoven".

fat-lobyte hat geschrieben:

Xin hat geschrieben:Weil ich das Hin- und Herkopieren nicht gut finde - vor allem weil es Zeit kostet -

Es kostet zwar Zeit, mit RValue references und richtig geschriebenen Konstruktoren nur mehr wenig. Außerdem sollten Compiler den Overhead erkennen und wegoptimieren.

fat-lobyte hat geschrieben:

Xin hat geschrieben:Ich bevorzuge einen zweistufigen Aufbau von Objekten: Das Fundament des Objektes wird aufgebaut (Speicher reserviert), anschließend beschickt man die Daten.

Das mag ich gar nicht. Ich will "Zombiobjekte" vermeiden. Mir gehts drum im Code das auszudrücken was ich denke.
Ich denke: mach hier ein Rechteck aus diesen Punkten. Wenns Probleme gibt sag bescheid (= Exception).
Was ich nicht denke: Mach hier bitte ein bisschen Speicher, dann setzen wir mal den einen Punkt, dann den anderen, dann musst du mir noch sagen ob alles in Ordnung war, und wenn ja dann machen wir weiter. Das finde ich extrem unschön.

fat-lobyte hat geschrieben:Objektorientiert heißt für mich, dass ich ein Objekt erstelle, und es nach der initialisierung sofort bereit ist. Wenn ich zum Code nach der deklaration komme (und es keine Exception gab), dann ist das Objekt fertig und ich kanns verwenden. Das ist genau die statische Garantie, die ich von C++ erwarte.

fat-lobyte hat geschrieben:

Xin hat geschrieben:Höre ich häufiger. Üblicherweise als Umschreibung für zu aufwendig, nicht umsetzbar.

Du hasts erfasst. C++ ist sehr lange gewachsen, und nur ganz am Anfang durch die Hand eines einzigen Mannes. Es stecken viele, viele Arbeitstunden dahinter, von vielen ziemlich intelligenten Leuten. Dann stecken noch viel viel viel mehr (evtl. weniger intelligente) Augenpaare dahinter, die es verwendet haben und Probleme aufgezeigt haben. Dass du in deiner Lebenszeit etwas auf die Beine stellst, das konkurrenzfähig ist, und auch noch "Besser" sein soll als C++ glaube ich erst wenn ichs sehe . Nicht falsch verstehen - ich lass mich sehr gerne überraschen.

fat-lobyte hat geschrieben:Aber hier gleich mal mein Hauptkriterium für eine gute Sprache:
Ich will ausdrücken können was ich denke. Die Konzepte will ich mit möglichst wenig Syntaktischem Overhead aufs papier bringen. Was ich nicht will ist es mit dem Compiler zu spielen, damit er tut was ich will oder mich in die Hardware einarbeiten wo ich für ein Paar Optimierungen den "Kopf brechen" muss - das soll verdammt noch mal der Compiler machen, dafür gibts ihn ja.
C++ mit seinen Templates ist (zumindest auf der Bibliotheks-Anwenderseite) verdammt gut darin. Kannst du das toppen?

fat-lobyte hat geschrieben:

Xin hat geschrieben:Es gibt kein 'gut für alle Zeiten'. Ich habe keine Ahnung, was morgen kommt. Aber es gibt ein erreichbares "Gut" in der Gegenwart. Ich kann in der Gegenwart darauf hinweisen, was man in der Zukunft gut machen könnte. Und wenn das dann jeder macht, dann ist der Artikel veraltet.

Hm, da hast du vielleicht recht. Da sollte ich vl. meine Einstellung dazu ändern. In dem konkreten Fall würde sichs auszahlen auf die Zukunft zu setzen, denn sowohl beim GCC als auch bei Clang stehen da schon verdammt viele "Ja"'s bei den Features. Visual Studio hinkt noch nach, es wurde aber versprochen dass in den nächsten 1-2 Jahren auch außerhalb der Visual Studio Major-releases nachzurüsten.
GCC-4.6 hat schon genug, dass man echt und Effektiv Programmieren kann. 4.7 sollte nicht weit weg sein.

fat-lobyte hat geschrieben:

Xin hat geschrieben:Machst Du bei GDB/GIT weiter?

Ja, kann ich machen. Was ich nicht machen kann ist dir ein Versprechen abzugeben wann das geschieht. Leider.

Xin hat geschrieben:Und bevor ich das jetzt kompiliere, weiß ich, dass das falsch ist, weil es das beliebte Beispiel ist, um das Chaos von Variablendeklarationen mit dem Standard-Konstruktor, bzw. verkorksten Funktionszeigerdefinitionen.

Xin hat geschrieben:

Code: Alles auswählen

    A a=B();
oder bei explicit:
    A a = A(B());    

Wirklich nicht schön - aber nicht wirklich ein Problem.

Das Problem - die Funktionszeigerdeklarationen, die jeder ja jeden Tag benötigt, könnte man durch einen Kompatiblitätsmodus aus C herausoperieren. Macht man aber nicht.

Stattdessen bevorzugt man, dass man laufend diese Quizfrage gestellt bekommt.

Xin hat geschrieben:

fat-lobyte hat geschrieben:

Xin hat geschrieben:Du legst temporäre Objekte an, um sie zu kopieren.

Eben nicht! Das musste ich bisher, jetzt kann ich sie statt zu kopieren in das Objekt "hineinmoven".

Und das konntest Du vorher nicht?

Xin hat geschrieben:Hier wird es schwierig, denn was ein Compiler aus einer Initialisierungsliste macht ist nicht zwangsläufig das, was die Sprache semantisch hergibt. Sich darauf zu verlassen, dass der Compiler das Problem löst/wegoptimiert, obwohl die Sprache das semantisch gar nicht ausdrückt, kann zu interessanten Unterschieden zwischen Debug und Releaseversion führen.
Ich sehe hier keinen "Move".

fat-lobyte hat geschrieben:Aber hier gleich mal mein Hauptkriterium für eine gute Sprache:
Ich will ausdrücken können was ich denke. Die Konzepte will ich mit möglichst wenig Syntaktischem Overhead aufs papier bringen. Was ich nicht will ist es mit dem Compiler zu spielen, damit er tut was ich will oder mich in die Hardware einarbeiten wo ich für ein Paar Optimierungen den "Kopf brechen" muss - das soll verdammt noch mal der Compiler machen, dafür gibts ihn ja.
C++ mit seinen Templates ist (zumindest auf der Bibliotheks-Anwenderseite) verdammt gut darin. Kannst du das toppen?

Ja.

Xin hat geschrieben:Du und ich benutzen Linux. Wenn jemand C oder C++ lernen möchte, dann ist sein primäres Ziel C und C++ zu lernen. Eventuell unter Windows.
Ich benutze aktuell den GCC 4.4. Meine Programme kompilieren auch mit VC2010.

Xin hat geschrieben:In der Firma habe ich das Problem, dass einige Programmteile mit VC6 kompilieren müssen. Das ist schon leicht extrem, aber alte Compiler unterstützen zu müssen ist in Firmen ein recht übliches Problem.

Xin hat geschrieben:Ich lasse weiterhin jeden meiner Schüler mit C-Strings und selbstgeschriebenen Listen arbeiten, sowie Klassen dafür entwickeln und am Schluss Templates dafür entwickeln. Danach dürfen sie std::string oder std::vector verwenden. Auch strlen() ist verboten, bevor sie es nicht selbst geschrieben haben.

Der Weg programmieren zu lernen ist heute länger als vor 20 oder 30 Jahren, weil 20-30 Jahre Weiterentwicklung stattgefunden hat. Das Ziel 'Programmieren zu können' ist weiter weg. Aber um ans Ziel zu kommen gibt es keine Autobahn, keine Abkürzung und kein Wurmloch.

Abgesehen davon - die richtige Verwendung "alter" Techniken ist die Zukunft. Dafür sollte man nicht nur kennen, was zurzeit in Mode ist oder gehypt wird. Ansonsten wäre ich nämlich jetzt Ex-Delphi, Ex-Java, gegenwärtiger C#-Entwickler, statt seit bald 20 Jahren C++-Entwickler.

Alte Techniken sind in der Regel schneller als moderne

Ich denke, dass man sich vieles nochmal genau anschauen sollte und statt alternativer Lösungen sich vielleicht Gedanken machen kann, ob die alten Techniken nicht semantisch abgesichert werden können.
Und da geht einiges.

Auch wenn das durch Optimierung des Codes teils sicherlich obsolete ist, so wird eine Sprache damit eindeutig. Denn wenn jeder Konstruktor eine statische Variable hochzählt, dann stimmt entweder die statische Variable nicht bei allen Compilern oder die Optimierung wird dafür ausgeschaltet, obwohl der Entwickler gar kein zusätzliches, temporäres Objekt wünscht. Was der Entwickler wirklich will, muss er sagen können - unabhängig von der Optimizerstufe.

fat-lobyte hat geschrieben:

Xin hat geschrieben:Machst Du bei GDB/GIT weiter?

Ja, kann ich machen. Was ich nicht machen kann ist dir ein Versprechen abzugeben wann das geschieht. Leider.