visual c++ 6.0 author edition oder c++ builder 6 personal

Dravere schrieb:

Und wieso sollte man etwas nicht standardkonformes lernen? Ich meine moderne C++ Bücher können es auch Standardkonform, also wieso nicht gleich korrekt und zuerst falsch? Nicht sehr einleuchtend

pumuckl schrieb:

Du sagst, der Standard ist nicht so wichtig. Im Gegenteil, der Standard ist die Sprache. Jemandem das C++ des prä-standard VC6 beizubringen ist in etwa so sinnvoll wie im Deutschkurs das Deutsch des 18. Jahrhunderts zu lehren. Ist ja auch deutsch, ein paar Vokabeln sind zwar anders und der Schüler wird sich nicht immer verständlich machen können und noch öfter nichts verstehen - aber hey, das muss er am Anfang ja nicht, aktuelles Deutsch kann man ihm ja später beibringen? Wer heute noch nfängt mit VC6-C++ stößt irgendwann an seine Grenzen und darf dann feststellen dass er (z.B. um Boost zu verwenden) die Grenzen nur erweitern kann indem er die VC6-Eigenheiten wieder verlernt, danach Standard-Sprachmerkmale die beim VC6 wegen Inkompatibilität unter den Tisch gefallen sind nachholt und sich dann mit einer Bibliothek beschäftigt die für sich allein eigentlich schon anspruchsvoll genug ist.

Machen wir es doch einfach konkret am Beispiel des Threadstarters. wurstuk will c++ lernen und zwar schwerpunktmäßig in Richtung Spiele. Dafür hat er ein Buch aus dem Jahr 2005 ausgewählt, dass genau seinen Ansprüchen genügt. Ich kenne das Buch nicht, aber es hat zum überwiegenden Teil wunderbare Rezensionen bei Amazon.

Ich zietiere mal etwas aus der Inhaltsangabe:

Die ProgrammierspracheC++
...
1.2.3 Der ANSI-Standard
1.2.4 Warum gerade C++?
1.3 Jetzt geht es los...unser erstes Programm
...
1.4 Die Entwicklungsumgebung
1.4.1 Erstellen eines neuen Arbeitsbereiches mit Microsoft Visual C++ 6.0
1.4.2 Erstellen eines neuen Arbeitsbereiches mit Microsoft Visual C++ .NET 2003
1.4.3 Das Programm mit Hilfe des Quelltexteditors eingeben
1.4.4 Laden der Programmbeispiele von CD
1.4.5 Das Programm kompilieren, linken und ausführen
1.4.6 Ausführen des Programms
1.4.7 Der Unterschied zwischen Debug und Release
...
2.10 Casting: Erzwungene Typenumwandlung
2.10.1 Casting im C-Stil
2.10.2 Casting mit C++
...
STL – was ist das?
9.1.1 Vektoren
9.1.2 Verkettete Listen
9.1.3 Strings
9.1.4 Maps und Multimaps
...
Ein Spiel mit der SDL
12.1 Die SDL – was ist das?
12.2 Erstellen und Einrichten des Projektes
12.2.1 Projekt mit Microsoft Visual C++ 6.0 anlegen
12.2.2 Projekt mit Microsoft Visual C++ .net 2003 anlegen
12.2.3 Die restlichen Quellcode-Dateien
...

VC6 ist mitgeliefert und wird im Buch explizit erklärt. Vermutlich sind auch die Projektdateien für VC6 auf der CD gespeichert. Warum!? Warum sollte er jetzt auf das Buch verzichten und einen ganz anderen Weg nehmen bzw. das Buch mit VC9 durcharbeiten? Wo sind die gewaltigen Hürden, die vielen Probleme, das viele falsche Zeug? Vermutlich ist 99.9% des Gelernten aus dem Buch auch heute noch unverändert und könnte bestenfalls sogar 1:1 auf VC9 übertragen werden (wenn man sich bereits einigermaßen sicher in den Menüs und Projekteinstellungen der aktuelle IDE bewegen kann, weil dazu sind ja keine Anweisungen im Buch).

Hinzu kommt, dass z.B. viele bekannte Bücher zur Spieleprogrammierung (z.B. von Scherfgen (der Rotznase ), Rudolph oder Zerbst) nur minimale Verwendung der STL machen, überhaupt kein boost verwenden sondern gleich in die Windowsprogrammierung, DirectX, irgendeine Engine, ... einsteigen (nebenbei teils auch mit VC6 ).

Man bekommt doch die STL, intensive Template-Kenntnisse und boost nicht geschenkt. Das sind Wochen und Monate an zeitraubenden Studien. Warum sollte man sich also damit beschäftigen, wenn es für das eigene Ziel zu dem Zeitpunkt noch irrelevant ist? Und warum die Finger von einem Compiler lassen, nur weil er etwas nicht kann, das zweifellos wichtig ist, aber mit dem man noch nix zu tun hat? Weil andere in ihren Firmen Probleme bei der Migration von tausenden Zeilen Code hatten? Das ist doch albern.

Und was für worstoks bevorzugtes Buch gilt, gilt auch für andere sehr gute Bücher, wie z.B. den Petzold u.v.a.

Der jeweilige aktuelle Standard führt doch keine neue Sprache ein, das sind doch keine Revolutionen die da stattfinden. Die intellektuelle Leistung vor jedes cout ein std:: zu schreiben und das .h hinter dem Headerfile wegzulassen bzw. eine Variable auch mal vor dem Schleifenrumpf zu deklarieren ist so gewaltig nicht.

Auf den Rest kommt es an, auf Vererbung, Kapselung, dynamische Speicherverwaltung, Operatorüberladung, Polymorphy, Zeiger, Referenzen, Exceptions ... das sind die Dinge die sich Anfänger klar machen müssen. Damit verstehen sie was c++ ausmacht, damit finden sie sich auch in fast jeder Bibliothek zurecht. Und von diesen Dingen muss man sich auch nichts abgewöhnen, denn die sind geblieben und werden bleiben. Dass daneben noch Bibliotheken existieren, die einem in vielerlei Hinsicht Arbeit abnehmen (wie STL, boost, ...) , dass ist schön aber für den Beginn nich so sehr von Bedeutung. Im Gegenteil ich kann mir gut einen Aufgabentext eines Dozenten vorstellen, der die Implementierung verketteter Listen verlangt, mit dem VERBOT die STL zu verwenden.

Außerdem hindert einem keiner daran mit mehreren Compilern parallel zu arbeiten. Teilweise ist das sogar nötig. Ich kann den Petzold mit VC6 durcharbeiten, irgendein Template-Buch mit VC9, ein wxWidgets-Buch mit MinGW, ein Buch von Herold mit Anjuta/gcc usw. ...

Also ehrlich Leute, ich weiß nicht wo euer Problem liegt.

asc

Kritiker schrieb:

Die ProgrammierspracheC++
...
1.2.3 Der ANSI-Standard
1.2.4 Warum gerade C++?
...
STL – was ist das?
9.1.1 Vektoren
9.1.1 Vektoren
9.1.2 Verkettete Listen
9.1.3 Strings
9.1.4 Maps und Multimaps

Das frage ich mich bei der Kapitelreihenfolge auch. Sorry, aber dieses Buch schreit ohne es gelesen zu haben wiedermal nach: C Buch mit etwas C++ gegen Ende. char* sollten in einem guten C++ Buch zumindestens nicht vor std::string stehen.

Wenn man C mit Klassen verwenden will... wem es Spaß macht. Aber etwas als C++ zu verkaufen, nur weil man irgendwo mal ein paar C++ Funktionalitäten anschneidet, aber sonst C verwendet, finde ich typisch für viele die ich heute kenne:
Keine Bereitschaft ihr Wissen mal zu aktualisieren.

Kritiker schrieb:

Der jeweilige aktuelle Standard führt doch keine neue Sprache ein, das sind doch keine Revolutionen die da stattfinden.

Also wenn ich mir die C++ Historie (auch die Zeit vor dem Standard) anschaue, gibt es von Zeit zu Zeit tatsächlich Revolutionen. Es wird zwar nicht das ganze Umgestellt aber wesentliche empfehlungen zu der Sprache gemacht.

Kritiker schrieb:

Die intellektuelle Leistung vor jedes cout ein std:: zu schreiben und das .h hinter dem Headerfile wegzulassen bzw. eine Variable auch mal vor dem Schleifenrumpf zu deklarieren ist so gewaltig nicht.

Das zwischen der nicht-"std::" Version und der "std::" Version sogar teilweise immense Verhaltensunterschiede gibt lassen wir jetzt mal außen vor. Auch die unterschiedlichen interpretierungen wie beispielsweise auto_ptr der sich je nach Zeit und Laune unterschiedlich verhalten hat, ignorieren wir auch mal.

Kritiker schrieb:

Auf den Rest kommt es an, auf Vererbung, Kapselung, dynamische Speicherverwaltung, Operatorüberladung, Polymorphy, Zeiger, Referenzen, Exceptions ...

Zeiger gehören aber nicht unbedingt in die ersten Kapitel, und std::string vereinfacht vieles das man ohne ihn nicht hätte. Warum char* und C-Bibliotheken intensiv verwenden wenn es erstmal um die Sprache geht (Und ich meine hier wieder mal nicht das die STL oder boost ins letzte Behandelt werden muss, aber es gibt einen grundlegenden Funktionsumfang den man kennen sollte - weil er viel vereinfacht).

Kritiker schrieb:

...das sind die Dinge die sich Anfänger klar machen müssen. Damit verstehen sie was c++ ausmacht, damit finden sie sich auch in fast jeder Bibliothek zurecht.

Grundlegende Entwurfskonzepte (wie z.B. Grundverständnisse von Iteratoren und Containern) sind ebenso wichtig. Und in allen aktuelleren Bibliotheken und Frameworks zu finden.

Kritiker schrieb:

Dass daneben noch Bibliotheken existieren, die einem in vielerlei Hinsicht Arbeit abnehmen (wie STL, boost, ...)...

Die Standardbibliothekt (einschließlich STL) IST C++. Nicht daneben irgendeine Bibliothek. Sie ist integraler Sprachbestandteil.

Kritiker schrieb:

Im Gegenteil ich kann mir gut einen Aufgabentext eines Dozenten vorstellen, der die Implementierung verketteter Listen verlangt, mit dem VERBOT die STL zu verwenden.

Ich halte den anderen Weg für sinnvoller: Grundlegende Funktionalitäten erstmal zu nutzen und anschließend sich um deren Aufbau zu kümmern.

Kritiker schrieb:

Also ehrlich Leute, ich weiß nicht wo euer Problem liegt.

Mein Problem liegt an verbohrten Entwicklern die keine Bereitschaft haben das es mal Neuerungen gibt. Die einen schlecht geschriebenen C-Code als der STL-Überlegen präsentieren, ohne jemals einen Vergleich gemacht zu haben. Entwickler die eine Anwendung trotz Problemen mit neuen Betriebssystemen nicht portieren (wegen den "winzigen" C++ Bugs die der VS6 hat, was denen zuviel Aufwand für einen Umstieg ist). Mein Problem liegt dabei das ich Anfängern zu häufig Hilfe, wegen Probleme durch C-Altlasten geben durfte; Sachen die sie von vorne herein erstmal meiden könnten (und falls wirklich nötig immer noch später lernen können).

Ja, das Buch ist nicht das, was man unter einem modernen C++-Buch vorstellt. Die Stärken von C++, nämlich die Standard-Library, wird sehr stiefmütterlich behandelt. Bzw. es wird dem Leser nicht gleich zu Anfang vertraut gemacht.

@Kritiker! Sehr komisch das du die MSVC2003-Kapitel nicht fett dargestellt hast!!!

...
1.2.3 Der ANSI-Standard
1.2.4 Warum gerade C++?
1.3 Jetzt geht es los...unser erstes Programm
...
1.4 Die Entwicklungsumgebung
1.4.1 Erstellen eines neuen Arbeitsbereiches mit Microsoft Visual C++ 6.0
1.4.2 Erstellen eines neuen Arbeitsbereiches mit Microsoft Visual C++ .NET 2003
1.4.3 Das Programm mit Hilfe des Quelltexteditors eingeben
1.4.4 Laden der Programmbeispiele von CD
1.4.5 Das Programm kompilieren, linken und ausführen
1.4.6 Ausführen des Programms
1.4.7 Der Unterschied zwischen Debug und Release
...
2.10 Casting: Erzwungene Typenumwandlung
2.10.1 Casting im C-Stil
2.10.2 Casting mit C++
...
STL – was ist das?
9.1.1 Vektoren
9.1.2 Verkettete Listen
9.1.3 Strings
9.1.4 Maps und Multimaps
...
Ein Spiel mit der SDL
12.1 Die SDL – was ist das?
12.2 Erstellen und Einrichten des Projektes
12.2.1 Projekt mit Microsoft Visual C++ 6.0 anlegen
12.2.2 Projekt mit Microsoft Visual C++ .net 2003 anlegen
12.2.3 Die restlichen Quellcode-Dateien

MSVC 2003 ist sehr standardkonform, zumindest um ein vielfaches besser als VC6. Also, es wird doch sehr wohl eine neuere IDE/Compiler in dem Buch behandelt. Und MSVC 2003 unterscheidet sich von der GUI, den Menüs und den Wizards her nicht von 2005 und 2008. Denn mit VC 2002 und 2003 wurde die IDE umgekrempelt.

Jetzt muß ich doch erst Recht fragen: warum kann der Leser nicht 2005er oder 2008er nehmen??? Die Beschreibung dafür ist im Buch unter der 2003er-Anleitung vorhanden!!! Da kann ich doch nur noch mit den Händen über den Kopf schlagen und mich nur wundern, was der Leser mit VC6 soll?

wurstuk

Vielen Dank für die vielen Antworten!

Sry das ich noch nicht geantwortet habe, ich war im Urlaub

Ich glaube ich werde mir das Buch einfach mal kaufen und es versuchen durch zu arbeiten und wenn ich dann i-wie mit nim anderen Compiler (hoffe dis ist richtig geschrieben^^) Schwierigkeiten habe guck ich einfach mal nach nim anderen Buch^^

Nochmal vielen Dank für die vielen und schönen (und langen) Antworten

asc

wurstuk schrieb:

...

Viel Spaß mit C

Bulli schrieb:

Jetzt muß ich doch erst Recht fragen: warum kann der Leser nicht 2005er oder 2008er nehmen??? Die Beschreibung dafür ist im Buch unter der 2003er-Anleitung vorhanden!!! Da kann ich doch nur noch mit den Händen über den Kopf schlagen und mich nur wundern, was der Leser mit VC6 soll?

Ha! Wenigstens ist mir einer auf den Leim gegagen. Jetzt überleg einfach worauf es beim Durcharbeiten eines Buches ankommt und welch "großen" Unterschied es für die Erkenntnis macht wenn man DENSELBEN Quelltext auf VC6 oder VC9 durchgeht.

Trotzdem gibt es auch Gründe gegen VC9, jedenfalls zusammen mit diesem Buch, allgemein natürlich nicht(!) :
- .net 2003 gab es seinerzeit nicht kostenlos, man konnte es sich höchstens klauen
- VC6 ist auf der CD dabei, das spart Zeit
- Vieleicht will jemand seinen PC nicht mit dem .net-Kram zumüllen
- zu auftauchenden Probleme (die mit Sicherheit auch bei VC9 kommen) gibt es bei VC6 vermutliche viel mehr Material/Lösungen, weil das Ding einfach länger im Ulauf ist
- mitgelieferte Projektdateien können nicht so einfach in VC9 übernommen werden, man braucht zumindest eine Konvertierung bei der auch einiges schief gehen kann
- ...

Und so kommt eines zum anderen und es entstehen Probleme wo keine sein müssten, jedenfalls nicht für einen Anfänger.

asc schrieb:

Also wenn ich mir die C++ Historie (auch die Zeit vor dem Standard) anschaue, gibt es von Zeit zu Zeit tatsächlich Revolutionen.

Ich kenne jedenfalls keine, die grundlegendes Wissen über c++ obsolet gemacht hätten. Es kamen Dinge dazu (teils sehr wichtige Dinge, wie Templates), es wurde an Details gebastelt, aber im Groben funktioniert es noch genauso wie damals als ich damit angefangen habe (in den frühen 90ern)

asc schrieb:

Zeiger gehören aber nicht unbedingt in die ersten Kapitel, und std::string vereinfacht vieles das man ohne ihn nicht hätte. Warum char* und C-Bibliotheken intensiv verwenden wenn es erstmal um die Sprache geht (Und ich meine hier wieder mal nicht das die STL oder boost ins letzte Behandelt werden muss, aber es gibt einen grundlegenden Funktionsumfang den man kennen sollte - weil er viel vereinfacht).

Meiner Meinung nach gehören Zeiger unbedingt in die ersten Kapitel. Sie sind elementarer Bestandteil vieler Datenstrukturen, Algorithmen, usw. ... und natürlich müssen char-Arrays dran sein, BEVOR man std::string einführt. Meist ist das auch so. Jedenfalls kann ich mich gut erinnern, dass eine der ersten Aufgaben zu OOP oft der Bau einer eigenen String-Klasse war. Erst kommt das Verständnis, wie etwas funktioniert, dann erst kommen die Bibliotheken die einem das Leben erleichtern. Erst Kopfrechnen, dann Taschenrechner.

asc schrieb:

Grundlegende Entwurfskonzepte (wie z.B. Grundverständnisse von Iteratoren und Containern) sind ebenso wichtig. Und in allen aktuelleren Bibliotheken und Frameworks zu finden.

Ja, denn Sinn hinter Iteratoren zu verstehen bzw. selber welche zu bauen, das sind tatsächlich grundlegende ENTWURFSKONZEPTE. Wenn man sich aber mit Softwareentwurf beschäftig, dann sollte man beim Programmieren wirklich über die Anfängerphase hinaus sein, sonst hat das keinen Sinn. Das Iteratormuster ist jedenfalls im Buch der "großen Vier" erklärt und auf dem Umschlag ist ein Kreuz bei Fortgeschrittene, eines bei Profis und keines bei Einsteiger.

asc schrieb:

Die Standardbibliothekt (einschließlich STL) IST C++. Nicht daneben irgendeine Bibliothek. Sie ist integraler Sprachbestandteil.

Es ist eine (sehr nützliche) Bibliothek mit generischen Datentypen, die in den ANSI/ISO-Standard aufgenommen wurde, ja. Mehr aber auch nicht. Je nach Projekt ist man nicht darauf angewiesen oder muss teils sogar darauf verzichten (z.B. bei Threads).

asc schrieb:

Ich halte den anderen Weg für sinnvoller: Grundlegende Funktionalitäten erstmal zu nutzen und anschließend sich um deren Aufbau zu kümmern.

Bin kein Lehrer, daher kann ich nicht abschätzen was jetzt sinnvoller wäre, im Sinne von schneller, besser, nachhaltiger ... jedenfalls darf der Aufbau nicht zu kurz kommen.

Deine sämtlichen Argumente kommen meiner Meinung nach mehr aus der Sicht eines Entwicklers. Du musst aber bedenken, dass beim Erlernen einfach andere Dinge im Vordergund stehen. Hier haben Dinge wie einfach, sicher, plattformunabhängig, schlecht migrierbar, kostspielig, usw. noch keinen Platz. Das ist Anfangs noch Balast.

Gut, du merkst es ja selbst, wir sind wieder in einer Endlosschleife. Daher ist für mich zu dem Thema vorerst wieder alles gesagt. Ich denke ein (gelangweilter) Leser dieses Threads kann die Positionen erkennen, sich seine eigene Meinung bilden und entscheiden was er tut.

asc

Kritiker schrieb:

Deine sämtlichen Argumente kommen meiner Meinung nach mehr aus der Sicht eines Entwicklers. Du musst aber bedenken, dass beim Erlernen einfach andere Dinge im Vordergund stehen.

Ich bin vorgeschädigt mit Auszubildungsbetreuung und ähnlichen. Ich habe mir meine Meinung nicht ausschließlich über eigene Erfahrungen gebildet, sondern auch in Hinblick von den Problemen die bei unseren Azubis in der Schule aufgetreten sind.

Und char* sehe ich deshalb ebenso wie Zeiger erst nach std::string, weil im ersten Moment die Verwendung leichter ist.

Das nachfolgende Einführungsprogramm halte ich für leichter als erst entsprechendes in C zu machen.

#include <string>
#include <iostream>
using namespace std;

int main()
{
    cout << "Bitte geben sie ihren Namen ein: "

    string name;
    cin >> name;

    cout << endl << "Hallo, " << name;
}

Nach der Verwendung kann man dann in das Detail gehen (Was passiert hier im Hintergrund). Ich sehe keinen Zwang darin erst mit Zeigern und char-Arrays zu beginnen.

Zumindestens war meine Erfahrung die, das Azubis sich leichter etwas vorstellen können was recht einfach zu schreiben ist (Das oben ist nun wirklich nicht schwer), und dann in einen zweiten Schritt die Details lernen können.

Zum Beispiel kann man im obigen Beispiel die Anwendung recht gut zerlegen. Man kann z.B. nachdem man dieses Programm hat, daran gehen und zeigen was in etwa hinter dem string steckt (im ersten Schritt braucht man dazu keine Klassen). Man kann das Beispiel recht schnell um Funktionen ergänzen, und dann kurz ausholen, das Operatoren nichts anderes in C++ sein müssen...

cu André

Nexus

Kurze Stellungnahme meinerseits:

Ich finde es ehrlich gesagt auch nicht schlecht, wenn man zuerst von char -Arrays hört und später von std::string . Oder Arrays vor std::vector behandelt.

Natürlich ist es subobtimal, char[] gleich mit allem C-Kram einzuführen. Aber einfache Dinge, bei denen man nicht viel falsch machen kann, sind meiner Ansicht nach legitim. Gut ist, wenn man die mühsamen Operationen wie zusammenhängen, kopieren, zuweisen etc. mal erwähnt, aber vorläufig noch ignoriert.

Gleiches gilt allgemein für Arrays. Wenn man z.B. mehrere Werte per std::cin in die Konsole eingeben will und im Voraus nicht weiss, wie viele, erstellt man am Anfang halt ein (verschwenderisches) Array, damit man ungefähr sieht, was Arrays können. Später kann man sehen, dass das mit new und delete dynamisch funktioniert.

Dann... wird einem plötzlich klar, dass es in C++ eigentlich viel bessere Möglichkeiten gibt. Man kann durch Methodenaufrufe elegant Elemente an Container anhängen. Oder zwei Strings zusammenhängen, ohne in ständiger Angst um den Speicher leben zu müssen.

Das fördert bestimmt auch die Motivation des/der Lernenden. Gerade wenn man bestimmte mühsame C-Sachen bisher noch nicht behandelt hat, und somit einige Operationen gar nicht möglich wären, lernt man schöne Vorgehensweisen kennen. Wenn man von Anfang mit den C++-Konstrukten arbeitet, ist man tendenziell zu verwöhnt und schätzt diese Dinge gar nicht. Ich finde es gut, wenn man ein Verständnis dafür entwickelt, wie schwierig/mühselig einige Probleme zu implementieren sind. Das hilft einem später auch sicher weiter.

drakon

Ich sehe das ähnlich, wie Nexus.
Ich habe C++ auch dadurch gelernt, dass ich zuerst halt einfach ein paar mal mit Arrays und co. auf die Nase gefallen bin. Ich habe die Probleme, die es gibt Hautnah miterlebt und durfte da auch gewisse Fehler suchen gehen.
Und dann habe ich die Lösungsansätze kennengelernt, wie man jetzt eine "guten" String Klasse schreiben kann und sich somit ein Haufen arbeite sparen kann.
Das Problem, dass ich dahinter vermute std::string usw. zuerst zu benutzen ist, dass man sich nacher fragt, warum soll ich denn jetzt da Arrays lernen, wenn ich einfach std::vector benutzen kann und glücklich bin. (da dringt ev. Faulheit durch und man befasst sich mit den Grundlagen erst gar nicht mehr).

Dravere

Kritiker schrieb:

Der jeweilige aktuelle Standard führt doch keine neue Sprache ein, das sind doch keine Revolutionen die da stattfinden. Die intellektuelle Leistung vor jedes cout ein std:: zu schreiben und das .h hinter dem Headerfile wegzulassen bzw. eine Variable auch mal vor dem Schleifenrumpf zu deklarieren ist so gewaltig nicht.

Zuerst einmal ein paar Dinge dazu. Ich sehe da mehrere Probleme. Zum einen war da schon eine gewaltige Revolution, als man von NICHT-Standard zu Standard kam! Das musst du nämlich nicht vergessen. VS6 hat nicht den ersten Standard von 1998 unterstützt, sondern quasi noch sein eigenes Ding durchgezogen. Es wäre wirklich was anderes, wenn man zwischen VS2003 und VS2008 vergleichen würde. Da sind die Unterschiede nicht so heftig.
Aber auch in einem Vergleich zwischen VS2003 und VS2008, würde ich zu VS2008 raten. Und das hat einen einfachen Grund. Wieso sollte jemand mit VS2003 anfangen zu arbeiten um dann später sowieso wechseln zu müssen? Jede IDE verhält sich etwas anders, seien es noch so kleine Dinge. Wieso sollte man sich an etwas altes gewöhnen, wenn man gleich das neue verwenden könnte? Gewohnheiten kann man immer nur schlecht wieder loswerden.

Und genau auch die Gewohnheiten gelten für den Standard. Wenn man sich gewohnt ist auf eine gewisse Art und Weise C++ zu programmieren, wird man heftige Probleme haben, es in Zukunft anders zu machen. Das haben Gewohnheiten so an sich. Und für einen Neuling ist das ziemlich demotivierend, wenn er sich schon nach kurzer Zeit umstellen muss.
Wieso also nicht gleich das Neue erlernen und die alten Gewohnheiten gar nie bekommen?

Ich frage dich nocheinmal, vielleicht diesmal in eine bisschen abgewandelter Form:
Du kennst ein gutes Buch, wie man Win95 erlernt. Du bist nun der Lehrer oder Professor einer Gruppe, welche Betriebsysteme oder sagen wir Windows erlernen soll. Wirst du deinen Schülern das Buch zu Win95 empfehlen oder lieber nach einem guten Buch für WinXP oder WinVista suchen? Würdest du deinen Schülern wirklich zuerst Win95 beibringen? Oder gar noch schlimmer, vielleicht sogar DOS, damit sie auch begreifen, was im Hintergrund abgeht? Womöglich noch ein Betriebsystem zuerst selber zusammenfrickeln?

Kritiker schrieb:

Auf den Rest kommt es an, auf Vererbung, Kapselung, dynamische Speicherverwaltung, Operatorüberladung, Polymorphy, Zeiger, Referenzen, Exceptions ... das sind die Dinge die sich Anfänger klar machen müssen. Damit verstehen sie was c++ ausmacht, damit finden sie sich auch in fast jeder Bibliothek zurecht.

Und nun zu diesem Thema. Deine aufgelisteten Punkte, sehe ich alle als Themen für Fortgeschrittene an. Ein Anfänger sollte nicht bereits in der Lage sein, sich in anderen Bibliotheken zurecht zu finden. Ein Anfänger sollte die einfachsten Strukturen zuerst erlernen.

Ich kenne viele, welche probiert haben mit C++ anzufangen und damit zuerst einmal in die Abteilung Pointer reingeschmissen wurden. Das hat sie so demotiviert, dass sie ihr Buch nie fertig gelesen haben. Wenn ich mit ihnen heute rede, dann kommt die Antwort, dass C++ doch eine scheiss Sprache sei, weil man da immer Zeiger rumwirft. Wenn man dagegen die Standardbibliothek verwenden würde, würde sich diese Anzahl Zeiger um ein vielfaches reduzieren.

C++ ist keine anfängerfreundliche Sprache, da muss man es nicht noch verstärken, indem man gleich zu Beginn mit Zeiger um sich wirft. Es gibt so Masochisten, wie drakon, Nexus, vielleicht asc und Kritiker, und auch ich, welchen diese Zeiger zu Beginn richtig gefallen, weil diese sehen, was für Mordwerkzeuge das sind. Es gibt aber viele, welche die Schmerzen nicht ganz so angenehm finden

Man sollte also zuerst den Anfängern etwas geben, was sie verstehen. Man sollte ihnen die bereits vorhandenen Konstrukte beibringen. Auf den Hintergrund kann man später immer noch eingehen. Wichtig ist zuerst einmal, dass sie mit den wesentlichen Werkzeugen von C++ umgehen können und diese Werkzeuge sind nunmal nicht Zeiger, sondern ist die Standardbibliothek (im übrigen nicht STL ).

Grüssli