Kostenlos "Visual C++ 6 - Das bhv Taschenbuch"

[Martin Richter]

Tachyon schrieb:

Was stimmt denn mit der enum-Syntax nicht?

VC6 erlaubt folgenden Syntax:

class  CMyClass 
{
...
public:
  enum EMyEnum
  {
     enum1, enum2, 
  };
...
};

...
void Foo()
{
...
   int i = CMyClass::EMyEnum::enum1;
...
}

EMyEnum ist kein Klassename oder Namespace und darf hier nicht verwendet werden.

... to be continued

[Tachyon]

Martin Richter schrieb:

Tachyon schrieb:

Was stimmt denn mit der enum-Syntax nicht?

VC6 erlaubt folgenden Syntax:

class  CMyClass 
{
...
public:
  enum EMyEnum
  {
     enum1, enum2, 
  };
...
};

...
void Foo()
{
...
   int i = CMyClass::EMyEnum::enum1;
...
}

EMyEnum ist kein Klassename oder Namespace und darf hier nicht verwendet werden.

... to be continued

Erlauben tut es das, ja. Aber es geht auch:

int i = CMyClass::enum1;

Nicht standardkonforme Erweiterungen gibt es auch bei neuen Compilern noch genug.
Viel schlimmer finde ich, das private-Enums trotzdem im public Sichtbarkeit haben.

[Martin Richter]

Tachyon schrieb:

Nicht standardkonforme Erweiterungen gibt es auch bei neuen Compilern noch genug.
Viel schlimmer finde ich, das private-Enums trotzdem im public Sichtbarkeit haben.

ACK! Den habe ich vergessen!

Ich kann mich schon gar nicht mehr an alle Bugs erinnern, sind einfach zu viele...

[Kritiker]

Martin Richter schrieb:

Genau! wenn man das Alter dieses Compilers ansieht, dann kann man ihn nicht mit gutem Gewissen empfehlen.

Selbstverständlich würde man heute einen aktuellen Compiler KAUFEN. Will man sich allerdings kostenlos in die MFC usw. einarbeiten (ohne zu klauen) steht die Autoren-Edition von VC6 alternativlos da.

Martin Richter schrieb:

Alleine was Templates, enum Syntax, for Scope betrifft ist es einfach nicht mehr zu vertreten.

Quatsch. Das mit dem "for-Scope" ist zwar ärgerlich. Es ist aber leicht zu umgehen, genauso wie die anderen Punkte.

asc schrieb:

Wenn es wenigstens 50% wären...

Jetzt übertreibst du aber gnadenlos. Seinerzeit galt eben ein anderer Standard und dazu ist VC6 weit mehr als 50% kompatibel. Und das Forum wird auch häufig genug mit Fragen konfrontiert, in welchen bemängelt wird, dass die Programme aus dem Stroustrup u.a. auf aktuellen Compilern nicht funktionieren.

asc schrieb:

Was ist die Standardbibliothek bzw. STL? Kann man das Essen?

Aha, weil ein paar Kleinigkeiten nicht funktionieren, kann VC6 kein STL?

pumuckl schrieb:

Das bedeutet aber nicht, dass es nicht wichtig wäre, einen möglichst großen Teil des Standards abzudecken. Wenn es ok wäre, dass man alle Nase lang über Fehlermeldungen stolpert, wo andere Compiler problemlos den Code schlucken, dann bräuchte man garkeinen Standard.

VC6 "schluckt" einen großen Teil des Standards. Abgesehen davon, ist man bei (fast) jeder Applikation recht schnell in einem Framework drin (GUI, Grafik, Multimedia, irgendeine API ...), so dass die, sicher vorhandenen, Nachteile bzgl. des Standards vernachlässigbar sind, wenn man stattdessen eine Menge anderer Dinge geboten bekommt. Klingt jetzt zwar blöd aber, ehrlich gesagt, kann ich drauf pfeifen ob eine Enum-Komponente public statt private ist, wenn ich (fast) problemlos mit der WinAPI, ATL, MFC, COM, DirectX, den ganzen Development Kits, usw ... arbeiten kann.

Bulli schrieb:

Suuuper, nicht mal ne einfache Library wie SFML kann man benutzen! Weil er so ne einfache Sache wie std::size_t nicht kennt.

Anscheinend programmierst du kein C++, sonst würdest du nicht so reden.

Sollte diese (ca. ein Jahr alte) Library nicht mit VC6 übersetzt werden können, so liegt das in der Verantwortung der Entwickler von SFML. Du kannst wohl schlecht erwarten, dass ein 10 Jahre alter Compiler das Ding ohne Probleme unterstützt. Wenn du SFML (ohne zusätzliche Arbeit) verwenden willst, dann darfst du eben nicht VC6 verwenden. Andere Frameworks hingegen arbeiten problemlos mit dem Compiler zusammen. Wenn etwas nicht funktioniert, dann verwendest du es eben nicht. Kein Compiler tritt mit dem Anspruch an jedes Framework zu übersetzen.

Und (bevor wir vom Thema abschweifen) was hat das alles mit C++ zu tun? Die Header im Stroustrup sind auch nicht mehr standardkonform und trotzdem handelt es sich dabei um C++.

Mit VC6 hat man einen völlig ausreichenden Compiler+IDE um sich in grundsätzliche Dinge einzuarbeiten. Das Ding ist gut dokumentiert und es existiert massenweise Literatur dazu. Trotz der Mängel ist es ein mächtiges (und begehrtes - siehe ebay) Werkzeug, das auch über 10 Jahre später noch produktiv eingesetzt wird. Es liegt in der Natur der Sache, dass die neuen Compiler besser sind, aber wer behauptet mit VC6 kann man nicht vernünftig arbeiten oder nicht C++ erlernen, der redet Unsinn. Würde mich nicht wundern, wenn an Schulen/FHs/UNIs sogar noch die 5er-Version zur Durchführung der Übungen eingesetzt wird.

Ob das Buch etwas taugt ist wieder eine andere Sache.

[asc]

Kritiker schrieb:

Will man sich allerdings kostenlos in die MFC usw. einarbeiten (ohne zu klauen) steht die Autoren-Edition von VC6 alternativlos da.

Das ist aber auch der einzige Pluspunkt.

Kritiker schrieb:

Quatsch. Das mit dem "for-Scope" ist zwar ärgerlich. Es ist aber leicht zu umgehen, genauso wie die anderen Punkte.

Die Punkte sind nicht leicht zu Umgehen, spätestend bei den Templates nicht mehr, und vor allem - für einen Anfänger sind die Probleme erst ersichtlich wenn er Hilfe braucht, auch wird er nicht wissen wie er mit den Eigenheiten des Compilers umgehen muss (und damit können ihn heutzutage nur noch wenige wirklich helfen).

Kritiker schrieb:

asc schrieb:

Wenn es wenigstens 50% wären...

Jetzt übertreibst du aber gnadenlos. Seinerzeit galt eben ein anderer Standard...

Ich übertreibe nicht, zumal es egal ist was damals für ein Standard (nämlich keiner, jedenfalls kein offiziell verabschiedeter) galt. Wir schreiben das Jahr 2008 - und der heutige Standard ist das, was ein Anfänger lernen sollte, nicht irgendwelchen nicht-konformen Schrott. Ganz davon abgesehen das der VC6 damals nach den, ich sage mal als Standard akzeptierten Vorlagen, auch nicht konform war.

Es ist auch vollkommen egal was veraltete Bücher besagen. Ansonsten ist die Welt eine Scheibe.

Kritiker schrieb:

asc schrieb:

Was ist die Standardbibliothek bzw. STL? Kann man das Essen?

Aha, weil ein paar Kleinigkeiten nicht funktionieren, kann VC6 kein STL?

Es sind bei weiten keine Kleinigkeiten, zumal es üblich ist auch aktuelle Bibliotheken (wie boost) zu verwenden. Und spätestens da scheitert es gnadenlos.

Kritiker schrieb:

VC6 "schluckt" einen großen Teil des Standards. Abgesehen davon, ist man bei (fast) jeder Applikation recht schnell in einem Framework drin (GUI, Grafik, Multimedia, irgendeine API ...), so dass die, sicher vorhandenen, Nachteile bzgl. des Standards vernachlässigbar sind, wenn man stattdessen eine Menge anderer Dinge geboten bekommt. Klingt jetzt zwar blöd aber, ehrlich gesagt, kann ich drauf pfeifen ob eine Enum-Komponente public statt private ist, wenn ich (fast) problemlos mit der WinAPI, ATL, MFC, COM, DirectX, den ganzen Development Kits, usw ... arbeiten kann.

Vielen geht es darum das ein Programm auch portierbar ist. Du kannst jedenfalls nicht garantieren wie lange eine unter VC6 geschriebene Anwendung noch lauffähig bleibt, und spätestens dann hat man gelinde gesagt verloren. Portier mal das Programm - ja du kannst den Standard umschiffen, aber nur wenn du auf jegliche Portabilität (Damit meine ich noch nicht einmal zwischen unterschiedlichen Arten von Betriebssystemen, sondern auch nur wenn es um die Umstellung auf neuere Compiler geht).

Kritiker schrieb:

Sollte diese (ca. ein Jahr alte) Library nicht mit VC6 übersetzt werden können, so liegt das in der Verantwortung der Entwickler von SFML. Du kannst wohl schlecht erwarten, dass ein 10 Jahre alter Compiler das Ding ohne Probleme unterstützt.

Mit Sicherheit liegt es nicht in der Verantwortung von Programmierern Compiler zu unterstützen die nicht mehr supportet werden. Und aktuelle Compiler sollten mit jeder Standardkonformen Bibliothek klarkommen, oder zumindestens sollten die Anpassungen minimal sein.

Und JEDER Entwickler der nicht einigermaßen aktuell bleibt, damit meine ich jetzt nicht täglich das neueste zu lesen, aber zumindestens seine Kenntnisse spätestens alle 4 Jahre aufzufrischen, hat den Titel Programmierer oder Softwareentwickler nicht verdient.

Kritiker schrieb:

Und (bevor wir vom Thema abschweifen) was hat das alles mit C++ zu tun? Die Header im Stroustrup sind auch nicht mehr standardkonform und trotzdem handelt es sich dabei um C++.

Aber nicht um aktuelles C++ - ganz davon abgesehen das ich mit den aktuellen Stroustrup keine Probleme habe; Bücher, gerade im IT-Bereich, werden auch von Zeit zu Zeit angepasst. Davon abgesehen wird es nach der Verabschiedung des nächsten Standards wohl auch wieder eine neue Version geben (geplant ist sie wohl schon).

Kritiker schrieb:

Es liegt in der Natur der Sache, dass die neuen Compiler besser sind, aber wer behauptet mit VC6 kann man nicht vernünftig arbeiten oder nicht C++ erlernen, der redet Unsinn.

Produktiv vielleicht (noch), C++ definitiv NEIN. Hallo, aufwachen, IT ist ein schnelllebiger Bereich - Der Standard ist nun 10 JAHRE alt. 10 Jahre sind für alle die nicht dauerhaft unter Nakose stehen durchaus eine Reaktionszeit in der man umstellen kann. Ich verlange ja garnicht eine native TR1-Unterstützung (5 Jahre alt) - aber das aktuell gültiges C++ ich sage mal zu 98% verstanden wird.

cu André

[Kritiker]

Ich arbeite es mal ohne Zitate ab.

Eigenheiten eines Compilers stellen für jeden Anfänger ein Hürde dar. Versucht man das "Standard-C++" ohne Buch/Tutorial zu einem Compiler/IDE zu lernen, hat man sowieso verloren. Z.B. legt ein aktueller Microsoft-Compiler bei der Neuerstellung eines Projekts diesen Code vor:

#include "stdafx.h"

int _tmain (int argc, _TCHAR* argv[])
{
	return 0;
}

Jetzt finde mal etwas darüber im Standard. Die Template-Probleme und boost-Geschichten sind nicht Anfängerrelevant. Bis auf die for-Schleifen schluckt auch VC6 alles was in typischen Einführungsbüchern/Skripten zu finden ist. Wenn du nicht der Meinung bist, dann bring doch einen Anfänger(!)-Code der mit VC6 größere Problem macht und nur noch von "älteren" Spezialisten durchschaut werden kann.

Portierbarkeit ist immer ein Problem. Auch du kannst nich garantieren, dass dein (mit aktuellem Compiler entwickelter) Code die nächste Generation der Entwicklungsumgebung, Bibliothek, usw. ... noch mitmacht.

Selbstverständlich sind die Entwickler von SMFL dafür verantwortlich welche Compiler von ihnen unterstützt werden. Wenn sie sich nicht die Mühe machen VC6 und andere ältere Compiler miteinzubeziehen, dann ist das eben so. Die Voraussetzung zum Einsatz einer Bibliothek kennt man doch vorher. Da gibt es in VC6 halt andere Möglichkeiten.

Nebenbei sind Portierbarkeit, Einsatz einer aktuellen Bibliothek, usw. nicht in jedem Projekt Schwerpunkt. Alter Code, der bereits gut gewartet ist und seine Aufgabe erfüllt ist häufig viel kostbarer.

Ich behaupte ja nicht, dass man seinen aktuellen Compiler wegwerfen soll um stattdessen lieber mit VC6 zu programmieren. Ich wehre mich nur dagegen das Ding so abzuqualifizieren.

Wenn jemand heute noch damit seine ersten Schritte in C++ machen will, dann kann er das auch, ohne irgendwelche Nachteile in Kauf zu nehmen. Die hier aufgeführten enum- und Templateprobleme kann man getrost vernachlässigen. Sie haben für das Grundsätzliche keine Bedeutung. Als Anfänger hat man sowieso wenig mit dem Standard zu tun, was auch völlig unnötig ist. Und wenn man sich bereits auskennt, weiß man auch wie man die Probleme umschifft bzw. man weiß was in dem jeweiligen Projekt wichtig ist und nimmt die entsprechenden Werkzeuge.

Wer soll was umstellen? Meine ersten Gehversuche in C++ fanden auf einem Borland-Compiler (Borland C++ 4.0) statt. Wenn man sich die alten Bücher ansieht, stellt man schnell fest, dass in der "schnelllebigen IT" zwar in Headern rumgefummelt wurde, Bibliotheken hinzugekommen sind, usw. ... aber die grundsätzlichen C++ Konzepte sind geblieben. Ein neuer Standard heißt ja nicht, dass der "alte" Kram vollständig Schrott ist.

Nebenbei sind Portierbarkeit, Lesbarkeit, usw. tolle Schlagwörter. Aber, ganz ehrliche, wer frickelt schon seinen alten Code an neue Anforderung um? Warten, Debuggen, usw. OK - aber, meist geht es doch wieder ganz von vorne los und der alte Code dient höchstens als Inspiration.

[asc]

Kritiker schrieb:

Z.B. legt ein aktueller Microsoft-Compiler bei der Neuerstellung eines Projekts diesen Code vor:

Abhängig von den Einstellungen. Davon abgesehen wäre es sogar noch ein Grund weiter gegen den VS6: Warum sich in einen Compiler einarbeiten der so langsam endgültig aus den Firmen verschwindet (Ja, ich widerspreche nicht das er noch vereinzelt eingesetzt wird).

Kritiker schrieb:

Die Template-Probleme und boost-Geschichten sind nicht Anfängerrelevant. Bis auf die for-Schleifen schluckt auch VC6 alles was in typischen Einführungsbüchern/Skripten zu finden ist.

Ich arbeite nun seit 2 Monaten nicht mehr in einer Firma mit den Compiler, aber wir hatten mehrere Sachen die auf unterer Ebene bereits Probleme bei dem Versuch der Portierung bereitet haben. Und davon war vieles in Bereichen die auch Anfänger verwenden.

xyz * p = new xyz();
if(!p)
...
for(...

Diverse Probleme in Standardheadern (ich weiß nicht mehr die genauen Stellen, der Portierungsversuch liegt glaube ich etwa 2 Jahre her, erinnere mich aber auch an einige stream-Probleme). Ja, natürlich, wenn man ausschließlich das MFC-Framework verwendet, hat man wenig davon gesehen.

Ganz davon abgesehen sehen hier in dem Forum schon einige Anfänger recht schnell ein paar Basisfunktionalitäten von boost, wir reden hier nicht vom selbst schreiben, sondern vom Einsatz. Und siehe da, schon scheitert man.

Davon abgesehen wollen Anfänger nicht immer Anfänger bleiben, warum unnötig weiteren Balast ihn aufhalsen. Und das einzige Argument für den VC6, die MFC, hat in Anfängerhänden, solange sie noch nicht das C++ Basiswissen haben, eh nichts zu suchen.

Kritiker schrieb:

Wenn du nicht der Meinung bist, dann bring doch einen Anfänger(!)-Code der mit VC6 größere Problem macht und nur noch von "älteren" Spezialisten durchschaut werden kann.

Wird schwer ohne den VC6, und nein, ich habe mich lange genug mit nicht standardkonformen Compilern (Power++ 2.5 und Visual C++ 6.0) herumgeschlagen um drüber fluchen zu dürfen. Ist immer wieder nett wenn man sein Wissen nicht einsetzen kann, weil man einfach zu aktuell ist...

Und was Templates angeht: Der VC6 steigt schon bei relativ einfachen Konstrukten aus, und zumindest das Basiswissen über Templates gehört für mich auch in ein C++ Grundlagenbuch; Templates sind einfach zu praktisch um sie gänzlich außen vor zu lassen.

Kritiker schrieb:

Portierbarkeit ist immer ein Problem. Auch du kannst nich garantieren, dass dein (mit aktuellem Compiler entwickelter) Code die nächste Generation der Entwicklungsumgebung, Bibliothek, usw. ... noch mitmacht.

Wenn du Standardkonform geschrieben hast, ist die wahrscheinlichkeit extrem hoch das der Änderungsaufwand minimal ist.

Kritiker schrieb:

Selbstverständlich sind die Entwickler von SMFL dafür verantwortlich welche Compiler von ihnen unterstützt werden. Wenn sie sich nicht die Mühe machen VC6 und andere ältere Compiler miteinzubeziehen, dann ist das eben so. Die Voraussetzung zum Einsatz einer Bibliothek kennt man doch vorher. Da gibt es in VC6 halt andere Möglichkeiten.

Ja, den VC6 garnicht erst nehmen. Für einen Anfänger gibt es kein, aber wirklich kein, Argument für den VC6. MFC ist UI-Programmierung, und die hat in C++ meines Erachtens in keinen C++ Grundlagenbuch auch nur ansatzweise etwas verloren (Und wenn überhaupt erst GANZ am Schluß; dann ist das Buch aber wieder auf ein Framework beschränkt, na Danke).

Kritiker schrieb:

Nebenbei sind Portierbarkeit, Einsatz einer aktuellen Bibliothek, usw. nicht in jedem Projekt Schwerpunkt. Alter Code, der bereits gut gewartet ist und seine Aufgabe erfüllt ist häufig viel kostbarer.

Ja, wenn das Wörtchen wenn nicht wäre... Wenn es nicht dazu kommt, das mit einem neuen Betriebssystem auf einmal einiges nicht mehr läuft.

Jetzt gibt es mehrere Möglichkeiten:
a) Gute Firmen sorgen dazu das man bei längerfristigen Projekten auch Wartung und Aktualisierungen von Zeit zu Zeit einplant. Man muss ja nicht jede Compilerversion mitnehmen, aber eine Anpassung spätestens alle 4 Jahre ist mehr als nötig, ansonsten ist das Programm ohnehin nicht mehr Wartbar.
b) Schlechte Firmen, mit einer guten Finanzdecke, reizen Compiler so lange aus bis nichts mehr geht, und passen dann an oder schreiben neu - die paar Kunden in der Zwischenzeit die Flöten gehen werden den Laden schon nicht in den Bankrott führen. Und wenn es Unwegbarkeiten im neuen Betriebssystem gibt - ist ja egal, dann wird einer einfach so lange daran gesetzt bis er einen neuen Flicken fabriziert - Selbst wenn dies mehr Zeit kostet als die Migration des Gesamtprojektes.
c) Schlechte Firmen mit nicht so guter Finanzdecke gehen daran zu grunde. Ein Plan X wurde niemals vorbereitet, und eine Portierung ist nicht drin.

Kritiker schrieb:

Ich behaupte ja nicht, dass man seinen aktuellen Compiler wegwerfen soll um stattdessen lieber mit VC6 zu programmieren. Ich wehre mich nur dagegen das Ding so abzuqualifizieren.

Jeder, der den VC6 Anfängern emfiehlt ohne die Konsequenzen zu erwähnen sollte nicht mit weniger als 200 Lehrstunden für diesen Anfänger bestraft werden. Wobei, nein, den in der Regel sind das auch die, deren C++ Code nicht grausamer sein könnte.

Kritiker schrieb:

Wenn jemand heute noch damit seine ersten Schritte in C++ machen will, dann kann er das auch, ohne irgendwelche Nachteile in Kauf zu nehmen. Die hier aufgeführten enum- und Templateprobleme kann man getrost vernachlässigen. Sie haben für das Grundsätzliche keine Bedeutung. Als Anfänger hat man sowieso wenig mit dem Standard zu tun, was auch völlig unnötig ist.

Mit was hat man den zu tun? Grundlagenwissen schließt den Standard mit ein (Alleine schon Dinge wie std::string, std::vector und Co seien hier angesprochen). Nicht hingegen haben irgendwelche Frameworks wie MFC ihn zu interessieren. Warum zur Hölle also nicht gleich einen aktuellen Compiler empfehlen und unnötige Probleme einfügen?

Kritiker schrieb:

Nebenbei sind Portierbarkeit, Lesbarkeit, usw. tolle Schlagwörter. Aber, ganz ehrliche, wer frickelt schon seinen alten Code an neue Anforderung um? Warten, Debuggen, usw. OK - aber, meist geht es doch wieder ganz von vorne los und der alte Code dient höchstens als Inspiration.

Alle Firmen die Standardlösungen anbieten? Es sind nicht alle Programme da drausen kurzzeitige Projekte. Sowohl das aktuelle wie auch mein letztes Projekt haben - bislang - Laufzeiten von ca. 10 bzw. 15 Jahren!

cu André

[pumuckl]

@Kritiker, der VC6 Compiler mag ja seinerzeit seine Schuldigkeit getan haben und auch ein guter Compiler gewesen sein. Das war aber vor den Zeiten des Standards. Heute sollte man erwarten dürfen dass man standardkonformen Code auf jedem Compiler übersetzen können sollte, wenn er sich nicht zu sehr in den dunklen Ecken des Standards bewegt (es gibt fiese template-Hacks die auch heute noch von nur wenigen Compilern richtig übersetzt werden). Leider streikt der VC6 schon bei ganz alltäglichen Dingen.

Kleine Analogie: Mit einem Oldtimer aus den Anfängen des Automobilbaus (sagen wir ende 19. Jh) darf ich nicht auf die Autobahn. Warum? Weil er nicht dem heutigen Verkehrsstandard entspricht, keine Gurte, Höchstgeschwindigkeit ist zu langsam, den Sprit an der Tanke verträgt er nicht usw. Wir als normale Verkehrsteilnehmer bezeichnen die Kiste als wertlos, vor allem für Fahrschüler. Du kommst jetzt an "wieso, Bremse, Lenkrad und Gaspedal ist doch immernoch das selbe, und fahren tut er auch noch..."

Vielleicht ist der Vergleich jetzt übertrieben, aber nur ein bisschen. Der VC6 ist ein Dinosaurier, und für mehr als ne Runde um den Hof taugt er nicht mehr, da viele aktuelle Frameworks auf dem aufbauen was er nicht kann. Viele der Techniken die so gerne als "modern C++" bezeichnet werden bauen stark auf templates, udn zwar so weit dass der VC6 schnell das Handtuch wirft.

[Kritiker]

@pumuckl
Irgendwie drehen wir uns im Kreis. Ich behaupte ja nicht, dass der VC6 für irgendetwas BESSER geeignet ist. Ich selbst sehe auch lieber den VC9 ein "succeeded" ausspucken, statt beim VC6 ein "...fatal...bla...bla...allocator...error" behandlen zu müssen. Mir geht es nur zu weit wenn man behauptet der VC6 kann kein C++ und sei insgesamt Schrott. Keiner würde heutzutage grundlos in einer Firma VC6 einführen, das ist klar. Aber, um bei deiner Analogie zu bleiben für eine Runde um den Block taugt er allemal. Und wenn man auf einem Oldtimer Gas, Bremse und Lenkrad bedienen kann, dann kann man es auch auf einem "autobahntauglichen" Fahrzeug.

@asc
Auch bei dir finde ich kaum Anlass zu widersprechen. Sicher ist die Portierung von VC6 auf VC9 nicht unproblematisch, allerdings auch nicht unmöglich. Denselben Code mit verschiedenen Compilern übersetzt zu bekomme ist auch was ganz Tolles. Allerdings, selbst wenn du dich brav an den Standard halten willst, kommst du relativ schnell an den Punkt wo du Funktionen, Konzepte, usw. verwenden MUSST, die Compiler-, BS-, oder Versionsabhänging sind und im Standard überhaupt nicht vorkommen. Dann bist du sowieso festgenagelt. Jetzt zeig mir bitte eine größere Applikation, bei der das nicht so ist. Selbst mit Frameworks die extra dafür gebaut sind (z.B. wxWidgets) wirst du bei der Portierung ein paar Probleme bekommen. Daher kannst du dich freuen, dass gewisse c++ Teile deiner Applikation 100%ig standardkonform sind, im Endeffekt bringt dir das aber kaum einen Vorteil, denn der weit größere Teil wird es nicht sein können.

Was die Anfänger angeht, so sieht man doch gewisse Muster. Zuerst verwendet jeder einen Mix aus C-Funktionen mit etwas C++, programmiert halb prozedural halb objektorientiert, verwendet Funktionen außerhalb des Standards, usw. usw. Wenn du da ankommst und sagst die Programme sind aber nicht standardkonform, dann ist das eine sinnlose Information. Mann muss zuerst gewisse Konzepte begriffen haben um dann später etwas mehr "Qualität" in den Code zu bringen.

Ich empfehle den VC6 ja auch nicht ausdrücklich, sondern behaupte nur, dass die "Folgen" weit weniger dramatisch sind als einige hier zu behaupten versuchen. Weltbewegende Codebeispiele seid ihr ja alle noch schuldig geblieben. Klar, irgendwo auf Seite 736 im einführenden Buch funktioniert ein geschachteltes Template nicht. Das gebe ich ja zu. Deswegen programmiert man aber immer noch in c++, weiß was die STL ist, was Vererbung ist, was virtuelle Funktionen sind, Zeiger, Exceptions usw. usw. ... denn das kann der Compiler alles. Und du sagst es selbst. Einige von uns mussten die Anfänge mit noch viel schlimmeren Compilern meistern. Watcom z.B. war auch mal sehr populär.

P.S.: Das einigermaßen aktuelle Compiler bei Bibliotheken nicht unbedingt vor Problemen schützen belegt ein Kollege ein paar Threads tiefer.
http://www.c-plusplus.net/forum/viewtopic-var-t-is-223204.html

[asc]

Kritiker schrieb:

Und wenn man auf einem Oldtimer Gas, Bremse und Lenkrad bedienen kann, dann kann man es auch auf einem "autobahntauglichen" Fahrzeug.

Aber nur nach einer Umgewöhnungsphase die es wirklich nicht nötig hat.

Kritiker schrieb:

Allerdings, selbst wenn du dich brav an den Standard halten willst, kommst du relativ schnell an den Punkt wo du Funktionen, Konzepte, usw. verwenden MUSST, die Compiler-, BS-, oder Versionsabhänging sind und im Standard überhaupt nicht vorkommen. Dann bist du sowieso festgenagelt.

Mehrschichtenarchitektur und Kapselung sagen dir wohl nichts. Man kann ohne probleme alle wesentliche Logik in ganz normalen ANSI C++ schreiben, und den Teil der auf das Framework basiert wird davon getrennt (in der Regel braucht man im Datenlayer spezifische Funktionen sowie auf ebene der GUI. Die Businesslogik braucht zumeist keinerlei solche Funktionen, außer vielleicht in den Schnittstellen wegen den unterschiedlichen Bibliothekkonzepten), das hat zudem weitere Vorteile wenn man es sauber kapselt:

a) Man hat die Möglichkeit einen Großteil des Codes selbst dann zu behalten falls die Kunden mehrheitlich auf ein anderes BS wechseln.
b) Datenlayer und GUI können leichter ausgetauscht werden (Bzw. man kann auch mehrere verschiedene Umsetzungen paralell fahren und muss vielleicht nur einzelne Programmteile (meistin Form von Bibliotheken) austauschen.

Kritiker schrieb:

...im Endeffekt bringt dir das aber kaum einen Vorteil, denn der weit größere Teil wird es nicht sein können.

Ich weiß nicht was an GUI und Datenlayer der weit größere Teil ist. Wenn man Projekte sauber aufsetzt, und diese für lange Zeit wartbar sein sollen, ist der weit größere Teil nicht mit Frameworkspezifischen Teilen durchsetzt. Ich beaupte das die Logik in einen Programm weit mehr als 50% in einen typischen Anwendungsprogramm ausmacht.

Kritiker schrieb:

Was die Anfänger angeht, so sieht man doch gewisse Muster. Zuerst verwendet jeder einen Mix aus C-Funktionen mit etwas C++,...

Nur wenn sie schlechte Bücher und Quellen erwischen, oder solche Bücher wie hier empfohlen bekommen. Es gibt einige Bücher die wirklich C++ und nicht C lehren. Der Umweg über C sehe ich auch als absolute Verschwendung an.

Kritiker schrieb:

...programmiert halb prozedural halb objektorientiert,...

Das wiederspricht nicht C++. C++ ist eine Multiparadigmensprache (Prozedural, Objektorientier und Generisch).

Kritiker schrieb:

...verwendet Funktionen außerhalb des Standards, usw. usw.

Und bekommt in der Regel spätestens wenn er in einem Forum wie diesen postet den Hinweis das er dies und jenes austauschen sollte. Und ich finde es deutlich schlechter den Stil zu unterstützen, als ihn von vorne herein schon etwas abzufangen. Weil Menschen nunmal Gewohnheitstiere sind und umlernen/umdenken zumeist auch nicht von Heute auf Morgen geschieht.

Kritiker schrieb:

Wenn du da ankommst und sagst die Programme sind aber nicht standardkonform, dann ist das eine sinnlose Information. Mann muss zuerst gewisse Konzepte begriffen haben um dann später etwas mehr "Qualität" in den Code zu bringen.

Man kann Konzepte und Qualität mit den richtigen Buch- und Compilerempfehlungen schon von vorne herein leichter umsetzbar machen. Das ein Anfänger auch dann noch einigen, ich sage mal Mist verzapft, liegt an der Natur der Dinge. Aber man muss ihn nicht zusätzliche Probleme mitgeben die Unnötig sind.

Kritiker schrieb:

Ich empfehle den VC6 ja auch nicht ausdrücklich, sondern behaupte nur, dass die "Folgen" weit weniger dramatisch sind als einige hier zu behaupten versuchen.

Wer sich das Forum anschaut, und sieht was man alleine schon an Problemen wegen der Compilerwahl und veralteter Literatur ausbügeln musste, wird eines besseren belehrt...

Kritiker schrieb:

...Weltbewegende Codebeispiele seid ihr ja alle noch schuldig geblieben.

...wird auch schwierig sein, den jeder der ernsthaft C++ Programmiert und durch die Firma nicht auf VC6 gezwungen wird, wird keinen VC6 mehr einsetzen. Die Probleme die ich aber gerade wegen:
a) Mangelnder Standardkonformität
b) Zu starker Verzahung von Framework im Projekt
Und ähnlichen Unwegbarkeiten die letzten 4 Jahre durchgemacht habe, sprechen eine andere Sprache. Ich will nicht wissen wieviele Stunden wegen solchen wirklich unnötigen Problemen draufgegangen sind, weil eine Firma nicht bereit war von Zeit zu Zeit (Obwohl man dank MSDN immer den neuesten Compiler besitzt) nicht mal versucht ob eine Portierung möglich ist, oder wo die Fallstricke liegen um sie dann zumindest schon etwas zu beseitigen.

Und ich bin schon bei einfachsten Bibliotheksfunktionen und Templateprogrammierung über die Unwegsamkeiten zweier Compiler gestolpert. Frag mich jetzt nicht was davon für VC6 galt, und was für Power++ aber hier mal eine kleine Liste:
a) Keine Defaultparameter in Templates
b) Keine Templatespezialisierungen
c) Probleme bei der Anwendung von Basisfunktionalitäten wie Streams und Vektoren

Kritiker schrieb:

Klar, irgendwo auf Seite 736 im einführenden Buch funktioniert ein geschachteltes Template nicht. Das gebe ich ja zu.

Wie schön das aber auch einzelne Codebeispiele außerhalb der Templates nicht funktionieren, und der Anfänger dann da steht und nicht weiß was er tun soll.

Kritiker schrieb:

Einige von uns mussten die Anfänge mit noch viel schlimmeren Compilern meistern. Watcom z.B. war auch mal sehr populär.

Nur weil wir es mussten, müssen nicht Anfänger mit den Folgen kämpfen. Das ist weder verantwortungsbewusst noch sinnvoll. Du sagst ja auch selbst das du nicht mehr zum VC6 greifen würdest - warum sollte es ein Anfänger?

Kritiker schrieb:

P.S.: Das einigermaßen aktuelle Compiler bei Bibliotheken nicht unbedingt vor Problemen schützen belegt ein Kollege ein paar Threads tiefer...

Wobei das keine Compilerprobleme sind...

cu André

[Kritiker]

@asc
Jetzt kann ich mich wirklich nur noch wiederholen. Ich verstehe ja deinen Standpunkt und keiner hat gesagt verwende VC6 wenn du auch auch VC9 (oder Ähnliches) zur Verfügung hast. Mir geht es alleine darum, dass man mit VC6 (vielleicht sogar mit diesem Buch) ebenfalls C++ erlernen kann und die Dämonisierungen hier reichlich übertrieben sind.

Schon alleine die Behauptung der ANSI-Standard ist "richtiges" oder "ernsthaftes" C++ und der Rest hat mit C++ nichts zu tun ist Quatsch. Wurde boost erst zu C++ weil es in den Standard aufgenommen wurde? Und die Teile von boost, die noch nicht drin sind? Sind die kein C++?

asc schrieb:

Mehrschichtenarchitektur und Kapselung sagen dir wohl nichts.

Mehrschichtenarchitektur hat mit dem Thema nichts zu tun. Du magst in der "Businesslogik" ANSI-C++ erzwingen können, aber das ist bei weitem nicht die Regel. Nimm einfach Threads als Gegenbeispiel.

asc schrieb:

Es gibt einige Bücher die wirklich C++ und nicht C lehren. Der Umweg über C sehe ich auch als absolute Verschwendung an.

Das ist Ansichtssache. Manche Autoren sehen C als wichtigen Teil von C++ und halten Kenntnisse in dem Bereich für hilfreich.

asc schrieb:

Das wiederspricht nicht C++. C++ ist eine Multiparadigmensprache (Prozedural, Objektorientier und Generisch).

Ob C++ wirklich objektorientiert ist, kann mit Recht bezweifelt werden. Auf jeden Fall ist es eine gute Mischung oder ein gutes Durcheinander aus vielen Konzepten.

asc schrieb:

Wer sich das Forum anschaut, und sieht was man alleine schon an Problemen wegen der Compilerwahl und veralteter Literatur ausbügeln musste, wird eines besseren belehrt...

Ideal ist der passende Compiler zum jeweiligen Buch, das ist schon klar, aber selbst wenn nicht, halten sich die Probleme doch im Rahmen. Nebenbei ist ein altes Buch nicht immer veraltet. Den Petzold z.B. arbeitet man am besten mit VC6 durch und der Inhalt des Buches ist und bleibt fundamental.

asc schrieb:

...wird auch schwierig sein, den jeder der ernsthaft C++ Programmiert und durch die Firma nicht auf VC6 gezwungen wird, wird keinen VC6 mehr einsetzen.

Zu Dingen wie "ernsthaft C++" habe ich oben bereits etwas gesagt. Die Standard-Bibliotheken sind beliebt, keine Frage, aber andere Bibliotheken sind es auch. Häufig kannst du mit dem Standard-Kram auch nicht so sehr viel anfangen. Wer nicht standardkonform programmiert programmiert dennoch "ernsthaft" C++.

asc schrieb:

Du sagst ja auch selbst das du nicht mehr zum VC6 greifen würdest - warum sollte es ein Anfänger?

Ich sage nicht ein Anfänger SOLLTE es tun. Ich sage nur wenn er es denn tut, dann sind die "Hürden" nicht so groß wie ihr sie hier darstellen wollt. Und wenn der Anfänger sich bereits nach kurzer Zeit exzessiv mit Template-Spezialisierung usw. befassen will, dann kann/muss er wechseln. Wenn er z.B. die (Haus)Aufgabe bekommt etwas auf Linux/UNIX zu machen, muss er auch einen anderen Compiler verwenden. Von anderen Programmiersprachen, die er vielleicht auch noch beherrschen will/muss brauchen wir erst gar nicht zu reden. Du selbst hast gesagt die IT ist schnelllebig.

Gut, ich denke die Standpunkte sind klar geworden. Falls nichts gravierendes mehr kommt, war es das für mich zu dem Thema. Es bringt ja nichts die Argumente ständig zu wiederholen.

[pumuckl]

Kritiker schrieb:

asc schrieb:

...wird auch schwierig sein, den jeder der ernsthaft C++ Programmiert und durch die Firma nicht auf VC6 gezwungen wird, wird keinen VC6 mehr einsetzen.

Zu Dingen wie "ernsthaft C++" habe ich oben bereits etwas gesagt. Die Standard-Bibliotheken sind beliebt, keine Frage, aber andere Bibliotheken sind es auch. Häufig kannst du mit dem Standard-Kram auch nicht so sehr viel anfangen. Wer nicht standardkonform programmiert programmiert dennoch "ernsthaft" C++.

Die anderen beliebten Bibliotheken verlassen sich aber auch auf die Gültigkeit des Standards und fallen damit bei VC6 schneller auf die Nase als bei anderen Compilern