anfängerfreundliches C++ Tutorial gesucht

[Der Martin]

n'Abend!

Modellieren wir doch einfach mal ein Kraftfahrzeug als Klasse...
Das finde ich ein ziemlich gutes Beispiel. Es beinhaltet auch die wesentlichen Merkmale der Objektorientierung Kapselung, Vererbung, Polymorphie, Abstraktion.

Stimmt, das ist mir aber auch hinterher erst bewusst geworden.

Aber du hattest ja gemeint, dass die prozedurale Denkweise mehr der natürlichen Denkweise des Menschen entspricht. Wie würde man also "prozedural" ein Auto programmieren?

Gar nicht - man würde die Sache ganz anders angehen. Beim prozeduralen Ansatz stünde der Vorgang im Vordergrund, also das Fahren. Man würde also eher eine Funktion schreiben

int drive(VEHICLE vehicle, LOCATION from, LOCATION to, PAYLOAD *payload);

Diese Funktion müsste dann bei jedem Schritt Eigenschaften der Struktur VEHICLE abfragen und auf alle möglichen Werte sinnvoll reagieren.

Dann muss ich modularisieren: ...
Diese Antwort hatte ich bereits erwartet, als ich meine letzte Antwort schrieb. Programmiertechnisch gesehen, bedeutet das du teilst deine große Funktion in mehrere kleinere Funktionen auf, damit du den Überblick behälst. Ist das aber nicht das gleiche wie wenn du versuchst den Sichtbarkeitsbereich deiner lokalen Variablen zu verkleinern?

Nicht ganz. Ich habe ja nicht kritisiert, scope-lokale Variablen zu verwenden. Beispiel:

for (i=0; i<SIZE; i++)
   { int square;
     square = i*i;

float root;
     root = sqrt(i);
   }

Mal abgesehen davon, dass diese Funktion nichts Sinnvolles tut, weil sie ihre Berechnungen nirgends ausgibt oder speichert: Ich meinte mit Unordnung nur die Deklaration neuer Variablen mitten im Anweisungsblock (hier: float root). Am Blockanfang (int square) ist das völlig okay und selbst im uralten K&R-C schon gültig. Und sinnvoll, denn jeder Block sollte eigentlich einen in sich abgeschlossenen logischen Schritt darstellen.

Die Variable Salatschüssel würde ich erst dann anlegen, wenn ich sie brauche um den Salat reinzutun. Der Fall dass das Anlegen der Salatschüssel mit einer ThereIsNoSchüsselInYourKitchenException fehlschlägt wäre glaube ich ein ernster Programmierfehler. Schließlich sollte ich keine Funktion salatZubereiten schreiben wenn ich keine Salatschüssel hab.

Ja, aber was ist, wenn du schon Essig und Öl angemixt hast, und dann schmeißt deine Salat-Methode plötzlich eine OutOfPepperException?

Wobei ich es durchaus zu schätzen weiß, dass ein C++-Compiler in der Regel auch dann einige Syntax-Features von C++ unterstützt, wenn er per Compiler-Option im C-Modus betrieben wird (etwa einzeilige Kommentare oder anonyme unions).
Sind das nicht sowieso Eigenschaften, die es seit C99 auch in C gibt?

Dein Freund David Tribble erwähnt anonymous unions als "an incompatible C++ feature" (was ich aus der Praxis nur teilweise bestätigen kann), aber Kommentare mit // sind seiner Aussage nach auch in C99 okay (das hatte ich beim ersten Überfliegen anders verstanden).

Diese beiden zusammen sind auch in der Tat mein liebstes Gespann. Dabei variiert der Assembler-Anteil je nach Projekt zwischen nahezu 0 und über 50%.
Dürft ich fragen wie groß deine Projekte dann im Normalfall sind?

Wenn der Assembler-Anteil sehr hoch ist, handelt es sich meist entweder um µC-Anwendungen (da auch manchmal über 80%) oder hardwarenahe, kleine Tools mit wenigen tausend Zeilen.
Die genaue Anzahl der Programmzeilen ist immer schwer anzugeben, weil der Compiler ja auch die -zigtausend Zeilen der includierten Headerdateien mitzählt, und allein die windows.h und ihre Tributaries machen ja schon an die 100'000 Zeilen aus.

Ich denke große Projekte in Assembler umzusetzen kann man durchaus eine kleine Kunst nennen, da man dafür ja schon eine ganze Menge wissen muss.

Die Größe des Projekts steht in keinem Zusammenhang mit dem nötigen Wissen. Es ist einfach eine Frage der Fleißarbeit. Wie du schon sagst, ist Assembler eigentlich nur in extrem zeitkritischen Bereichen sinnvoll, oder bei sehr hardwarenahen Projekten (z.B. Treiber für spezielle Hardware). Größere Codebereiche in Assembler zu coden, würde mir zwar Spaß machen, aber der Zeitaufwand geht ins Uferlose.

Ciao,
 Martin