C++-Tutorial

[Kerli]

Schließlich baut ja C++ auf C auf. Wir müssen dann halt nur ein einführendes Kapitel machen, in denen wir die Unterschiede beschreiben.

Naja... Vielleicht baut es theoretisch auf C auf, und vielleicht gibt es manche Menschen die dann in "C mit Klassen" Programmieren. Eigentlich ist es aber komplett anders, vor allem die Art wie man Programmiert und das was man tun sollte und nicht tun sollte. Einem Anfänger würde ich fast empfehlen zuerst C++ zu lernen, dann erst C.

Die Art wie man normalerweise programmiert ist zwar anders, aber die sprachlichen Grundlagen sind ja trotzdem die gleichen...
Aber ich würde sagen, dass es auch etwas Definitionssache ist

[Xin]

Schließlich baut ja C++ auf C auf. Wir müssen dann halt nur ein einführendes Kapitel machen, in denen wir die Unterschiede beschreiben.

Naja... Vielleicht baut es theoretisch auf C auf, und vielleicht gibt es manche Menschen die dann in "C mit Klassen" Programmieren. Eigentlich ist es aber komplett anders, vor allem die Art wie man Programmiert und das was man tun sollte und nicht tun sollte. Einem Anfänger würde ich fast empfehlen zuerst C++ zu lernen, dann erst C.

Könntest Du die Gründe mal genauer ausführen, ich mache beginne eigentlich immer mit C und wechsle dann frühzeitig auf C++.
Allerdings bin ich auch noch 'alte Schule', weiß dass das funktioniert und auch nicht von allem, was C++ an Libs mit sich bringt überzeugt. Vielleicht kannst Du mir die andere Seite ja näher bringen.

OOP zu erklären schließt sich ja mit dem Einstieg durch C nicht aus.

[fat-lobyte]

Naja... Vielleicht baut es theoretisch auf C auf, und vielleicht gibt es manche Menschen die dann in "C mit Klassen" Programmieren. Eigentlich ist es aber komplett anders, vor allem die Art wie man Programmiert und das was man tun sollte und nicht tun sollte. Einem Anfänger würde ich fast empfehlen zuerst C++ zu lernen, dann erst C.

Könntest Du die Gründe mal genauer ausführen, ich mache beginne eigentlich immer mit C und wechsle dann frühzeitig auf C++.
Allerdings bin ich auch noch 'alte Schule', weiß dass das funktioniert und auch nicht von allem, was C++ an Libs mit sich bringt überzeugt. Vielleicht kannst Du mir die andere Seite ja näher bringen.

Da gibt es so einige Konzepte. Beispielsweise gibt es in C++ viel weniger Gründe Zeiger zu verwenden, denn Referenzen kapseln die Details der Zeigerhandhabung weg. Fehler zu machen wird sehr viel schwieriger. Wenn man nicht gerade eine Referenz mit einem dereferenzierten Zeiger initialisiert, (int& p = *(int*) NULL), kann man keine Initialisierten Zeiger haben.
Außerdem wird sehr viel mit Destruktoren und Konstruktoren gearbeitet, damit kann man allein mit der "Lebenszeit" eines Objektes viel ausdrücken. Beispielsweise muss man in C eine Datei immer schließen. Ein C++ Filestream wird bei der Destruktion automatisch geschlossen. Wenn man das im zusammenhang mit dem "Scope" einer Variable betrachtet, wird das extrem nützlich. Bei Boost.Thread (also ws. auch bei der neuen Standardbibliothek) muss man, um eine ressource von threads zu versperren einfach ein objekt deklarieren. Wenn dieses Objekt "out of scope" geht, wird die ressource wieder entsperrt.

Dann gibts noch natürlich noch die Templates: sie liefern Allgemeinheit ohne Laufzeitoverhead.
Nicht nur dass, sie eröffnet ungeahnte möglichkeiten, zum Beispiel Metaprogrammierung. Boost.Spirit ist ein Parser Framework (Flex und Bison übernehmen z.B. ähnliche Funktionalität), das aus reinem C++ Code besteht, und mithilfe von dieser Template metaprogrammierung einen Parser aufbaut: zur Kompilierzeit!

Die STL ist eine gigantische Hilfe: Alle container die man braucht sind shcon implementiert.
Die meisten Container haben das gleiche Interface, sie können in vielen Verschiedenen Algorithmen verwendet werden. Die Algorithmen und Container der STL sind Allgemein, und äußerst effizient zugleich.

Die Operatorenüberladung erlaubt eine Integration von selbstdefinierten Typen in so einer Art, dass man manchmal vergisst, dass sie selbstdefiniert sind. Manchen Programmierern ist das ein Dorn im Auge, allerdings finde ich dass diese Möglich eine Intuitivere verwendung der Sprache erlaubt.


Zugegebenermaßen ist es für mich schwierig Beispiele zu Formulieren, vor allem weil sie bei sehr kleinen und einfachen Programmen (Beispielprogrammen eben) nicht sofort erkennbar sind. Der Unterschied in der Komplexität wird erst in großen Programmen bemerkbar. Vergleiche sind nicht leicht zu finden: wer schreibt denn schon ein Programm in C, um es dann sofort darauf in C++ zu schreiben?
Außerdem werde ich dich wahrscheinlich nicht überzeugen können: Du hast einen Lösungsansatz, ich habe einen Lösungsansatz. Natürlich glaube ich, dass meiner der "Beste" ist, und du glaubst dass deiner der "Beste" ist. Deiner hat vor- und nachteile, genau wie meiner. Hier einen Objektiven Vergleich zu treffen ist schwierig.

OOP zu erklären schließt sich ja mit dem Einstieg durch C nicht aus.

Natürlich schließt es das nicht aus. Nur ist es nunmal so, dass wenn jemand C++ lernen will, er nicht bei C anfangen muss.
Das ist ganz einfach nicht Notwendig. Manchmal ist es sogar hinderlich:
C- Programmierer werden lernen sich mit char* strings herumzuärgern, mit den ganzen strncat, strcpy, strtok und anderen schweinereien. (eine völlig Korrekte handhabung von char[]s ist einem Anfänger nicht zuzutrauen. Das öffnet allerdings sicherheitslücken!) Sie werden lernen, dass man einer Funktion - wenn sie ihren Parameter verändern soll - einen Zeiger übergeben muss. Sie werden Lernen, Verkettete Listen zu schreiben, sie werden lernen dass es keine Möglichkeit gibt über Fehler zu informieren, als über den Rückgabewert oder einen zusätzlichen Zeiger.
Und wieso lernen sie das? Wenn sie C++ anfangen, müssten sie alles von neu lernen. Sie haben eine sichere String klasse, sie haben Referenzen, sie haben die STL, sie haben Exceptions.
Das Gehirn allerdings ist nun schon auf C eingestellt. Sie empfinden C++ als "eine Nette erweiterung", eigentlich aber nicht viel mehr. Um meinen Praktikumsbetreuer zu zitieren: "C++ ist ja auch so eine Objektorientierte Programmiersprache, aber ich finde das ist nur künstlich auf C aufgesetzt." Dieser Spruch brachte ihm eine ziemlich hohe Augenbraue ein.

Ich hoffe ich habe meinen Standpunkt klar ausgedrückt. Hoffentlich versteht ihr jetzt, wieso ich immer ein bisschen genervt reagiere, wenn jemand sagt "ich lerne zuerst C, und dann später C++". Dieses später kommt aber meistens nicht.

[Metamorph]

Hoffentlich versteht ihr jetzt, wieso ich immer ein bisschen genervt reagiere, wenn jemand sagt "ich lerne zuerst C, und dann später C++".

Nein, ich verstehe es nicht.

Ich würde einem Anfänger nach wie vor empfehlen, zuerst mit C zu beginnen. Mich stört die andere Variante aber auch nicht.
Es stören mich aber die Leute, die krampfhaft ihre Meinung durchsetzen wollen und behaupten, dass es grundsätzlich falsch ist, mit C zu beginnen.

Diese Grundsatzdiskusionen sind lästig.
Fragen wie "Soll ich besser C lernen oder direkt mit C++ anfangen" wurden schon unzählige Male durchdiskutiert.
Die Antwort darauf ist, dass es keine gescheite Antwort darauf gibt.

C ist keine tote Sprache. Wir diskutieren hier nicht über Pascal.
Anfänger müssen darin harte Nüsse knacken.
Ich sehe es als Vorteil, die unkomfortablen Eigenheiten von C zu lernen und diese vorläufig nutzen zu müssen.
Damit meine ich die char-Felder, Referenzen durch Zeiger oder die Nullen und Einsen statt Booleanvariablen.
Der Anfänger ist "gezwungen", die "langweiligen" Themen zu beherrschen, um überhaupt ein ordentliches Programm entwickeln zu können. Das sind Grundlagen, die man in C++ braucht.

Hätte ich vorher nicht C gelernt, so wäre ich in C++ gescheitert.
C ist eine Untermenge zu C++. Die Codes lassen sich fast 1:1 in C++ übertragen.
Es ist auch vorteilhaft, wenn man in C++ die Grundlagen nochmals durchkauen muss. Eine kleine Wiederholung ist in solchen Bereichen nicht verkehrt.
Den Weg von C++ nach C finde ich sehr umständlich.

Ich mag C, obwohl mir C++ lieber ist.

Wir sollten einen Wikieintrag setzen, in dem diese Frage "beantwortet" wird. Imho sollte darin eine Pro-/Contra-Tabelle aufgelistet sein. Ich finde, dieser Beitrag sollte von mehreren Mitgliedern geschrieben werden, damit das Resultat nicht verfälscht wird und so ein gewisses Maß an Objektivität vorhanden ist.

[Kerli]

Referenzen durch Zeiger oder die Nullen und Einsen statt Booleanvariablen.

Also ich verwende das sehr wohl auch in C++...

Wir sollten einen Wikieintrag setzen, in dem diese Frage "beantwortet" wird. Imho sollte darin eine Pro-/Contra-Tabelle aufgelistet sein. Ich finde, dieser Beitrag sollte von mehreren Mitgliedern geschrieben werden, damit das Resultat nicht verfälscht wird und so ein gewisses Maß an Objektivität vorhanden ist.

Da bin ich einmal gespannt wer hier die C Anhänger sind

[Xin]

Allerdings bin ich auch noch 'alte Schule', weiß dass das funktioniert und auch nicht von allem, was C++ an Libs mit sich bringt überzeugt. Vielleicht kannst Du mir die andere Seite ja näher bringen.

Da gibt es so einige Konzepte. Beispielsweise gibt es in C++ viel weniger Gründe Zeiger zu verwenden, denn Referenzen kapseln die Details der Zeigerhandhabung weg.

Du weist, ich liebe Referenzen. Aber Zeiger sind weiterhin notwendig. Es fällt mir leichter den Nutzen von Referenzen zu vermitteln, wenn die Leute wissen, wie sie mit Zeigern Fehler machen.
Ich erkläre den Leuten gerne 'Hier habt ihr eine Lösung für ein Problem und hier gibt's ein neues Problem.' Und das wiederholt sich solange, bis die Leute programmieren können.

Außerdem wird sehr viel mit Destruktoren und Konstruktoren gearbeitet, damit kann man allein mit der "Lebenszeit" eines Objektes viel ausdrücken. Beispielsweise muss man in C eine Datei immer schließen. Ein C++ Filestream wird bei der Destruktion automatisch geschlossen. Wenn man das im zusammenhang mit dem "Scope" einer Variable betrachtet, wird das extrem nützlich.

Richtig. Und für einen Anfänger zu komplex, wenn er erstmal verstehen muss, wie eine Funktion arbeitet.

Dann gibts noch natürlich noch die Templates: sie liefern Allgemeinheit ohne Laufzeitoverhead.

Für einen Anfänger absolut nicht zu gebrauchen.

Nicht nur dass, sie eröffnet ungeahnte möglichkeiten, zum Beispiel Metaprogrammierung. Boost.Spirit ist ein Parser Framework (Flex und Bison übernehmen z.B. ähnliche Funktionalität), das aus reinem C++ Code besteht, und mithilfe von dieser Template metaprogrammierung einen Parser aufbaut: zur Kompilierzeit!

Ich kenne Spirit nicht, aber ich sehe Metaprogrammierung über Templates relativ kritisch. Und wieder sehe ich keine Chance, das einem Anfänger zu vermitteln.

Die Operatorenüberladung erlaubt eine Integration von selbstdefinierten Typen in so einer Art, dass man manchmal vergisst, dass sie selbstdefiniert sind. Manchen Programmierern ist das ein Dorn im Auge, allerdings finde ich dass diese Möglich eine Intuitivere verwendung der Sprache erlaubt.

Vergleichsweise einfach zu vermitteln, aber zuvor müssen Funktionen bekannt sein.

Zugegebenermaßen ist es für mich schwierig Beispiele zu Formulieren, vor allem weil sie bei sehr kleinen und einfachen Programmen (Beispielprogrammen eben) nicht sofort erkennbar sind. Der Unterschied in der Komplexität wird erst in großen Programmen bemerkbar. Vergleiche sind nicht leicht zu finden: wer schreibt denn schon ein Programm in C, um es dann sofort darauf in C++ zu schreiben?
Außerdem werde ich dich wahrscheinlich nicht überzeugen können: Du hast einen Lösungsansatz, ich habe einen Lösungsansatz. Natürlich glaube ich, dass meiner der "Beste" ist, und du glaubst dass deiner der "Beste" ist. Deiner hat vor- und nachteile, genau wie meiner. Hier einen Objektiven Vergleich zu treffen ist schwierig.

Ich sehe bisher nichts, was Du in C++ sinnvoll vermitteln kannst, ohne vorher C zu kennen.

Bevor jemand versteht, was cout macht, also was ein Objekt ist, muss er verstehen, was eine Methode ist. Und am Anfang stellt sich für mich die Frage, wie ich etwas programmiert bekomme, ohne den Anfänger mit Informationen zuzumüllen. Für C muss ich erklären, was includes sind, was Datentypen sind, wie eine (main)-Funktion aufgebaut ist und was der Rückgabewert bedeutet.
Hier hat PHP mal einen klaren Vorteil: print "Hallo Welt"; und fertig.
Und für C++ Hello World muss ich auch noch erklären, dass Datentypen klassifizieren und es statische Objekte gibt... Um einem Schüler einen nachvollziehbaren Start zu ermöglichen, muss er bereits verstehen, was er durch 'Hello World' lernen soll.
Den ersten Schritt in C finde ich schon recht aufwendig - in C++ überfordert er das Verständnis vollkommen.
Ich mag es nicht, den Schüler etwas tippen zu lassen, was er nicht nachvollziehen kann.

OOP zu erklären schließt sich ja mit dem Einstieg durch C nicht aus.

Natürlich schließt es das nicht aus. Nur ist es nunmal so, dass wenn jemand C++ lernen will, er nicht bei C anfangen muss.
Das ist ganz einfach nicht Notwendig. Manchmal ist es sogar hinderlich:
C- Programmierer werden lernen sich mit char* strings herumzuärgern,

Und ich quäle sie sehr damit und wer string-Verarbeitung mit std::string lernt, mit dem will ich nicht programmieren. Der hat nämlich vermutlich keine Ahnung von Arrays.

mit den ganzen strncat, strcpy, strtok und anderen schweinereien. (eine völlig Korrekte handhabung von char[]s ist einem Anfänger nicht zuzutrauen. Das öffnet allerdings sicherheitslücken!) Sie werden lernen, dass man einer Funktion - wenn sie ihren Parameter verändern soll - einen Zeiger übergeben muss. Sie werden Lernen, Verkettete Listen zu schreiben, sie werden lernen dass es keine Möglichkeit gibt über Fehler zu informieren, als über den Rückgabewert oder einen zusätzlichen Zeiger.

Blödsinn. Sie lernen Möglichkeiten, die notwendig sind und sie lernen weiter Möglichkeiten, wenn sie auf C++ wechseln. Und sie lernen Vor- und Nachteile der einzelnen Möglichkeiten.

Und wieso lernen sie das? Wenn sie C++ anfangen, müssten sie alles von neu lernen. Sie haben eine sichere String klasse, sie haben Referenzen, sie haben die STL, sie haben Exceptions.
Das Gehirn allerdings ist nun schon auf C eingestellt. Sie empfinden C++ als "eine Nette erweiterung", eigentlich aber nicht viel mehr.

Dann gebe ich Deinem Vorurteil mal Futter: C++ ist zu großen Teilen eine Erweiterung zu C.

OOP habe ich nicht in C++ gelernt oder in einer Sprache, die als objektorientiert gilt, sondern in C. Man kann in C problemlos OOP programmieren und ganz ehrlich, wer es in C mal gemacht hat, der weiß, was er tut und der weiß auch, warum er danach C++ nimmt.
Ich halte auch von Exceptions nicht viel - um ehrlich zu sein, ich halte sie für eine Fehlentwicklung, denn sie kostet Rechenleistung und wird in der Regel so angewandt, dass vor dem Absturz des Programms eine Popup-Box aufgeht, die mich darauf hinweist, dass meine Daten verloren sind, sobald ich auf 'Okay' drücke und mich dann bittet auf den einzig vorhanden Button mit der Aufschrift 'Okay' zu drücken. Exceptions? Sehr gute Idee, in meinen Augen nur leider an der alltäglichen Realität vorbei. Faktisch bliebt bei den meisten Programmen über, dass die Programme gebremst werden und dafür über überhaupt keine brauchbare Fehlerbehandlung mehr verfügen.

In dem Fall und besonders in dem Fall hoffe ich darauf, dass die Leute verstehen, wie Fehlerbehandlung in C aussieht. Wo nämlich kein Sicherungsseil ist, da gehen die Leute vorsichtig. Exceptions bieten Sicherheit - und die in der Regel genutzte Möglichkeit Verantwortung weiterzureichen, bis keiner mehr weiß, was eigentlich passiert ist und man das ganze nur noch an das Popup weiterreichen kann.

Programmieren lernen bedeutet jahrelang zu lernen und Erfahrungen zu sammeln, denn niemand hat sich bisher die Mühe gemacht, eine Sprache erst zu lernen und dann ein ganz wichtiges Projekt zu beginnen. Alle lernen programmieren in der Praxis. Es gibt keinen Weg, Programmieren zu lernen, ohne unsichere und falsche Programme zu schreiben.