Von "C++ von A bis z" zu "C++ Primer"

[pumuckl]

cooky451 schrieb:

9: globales namespace std;

Ist in dem Fall kein Problem. Die restlichen Kommentare stimmen aber.

weiteres zum Code:

15: Klassennamen ausschließlich in Großbuchstaben zu schreiben ist unkonventionell (d.h. für jeden anderen irritierend), sowas ist normalerweise #defines und evtl. enum-werten vorbehalten

18: Membervariablen sollten grundsätzlich private sein.

22: benutze Initialisierungslisten, um Membervariablen in Konstruktoren Werte zuzuweisen.

28: vermeide default-Konstruktoren, wenn sie nicht sinnvoll sind. D.h. schreibe sie nicht nur um Kompilerfehler zu beseitigen.

80: Wo ist die Fehlermeldung? Über ein Programm dass sich kommentarlos beendet freut sich niemand.

11/102: Statt globaler Variablen sollten deine Funktionen Ergebnisse zurückgeben.

123: 340 Zeilen für ein Funktion ist definitiv zu lang, das solltest du sinnvoll aufsplitten.

128: definiere Variablen dort wo du sie brauchst, nicht wie in C am Anfang der Funktion

170: neu erstellte strings sind immer leer, die brauchst du nicht zu clearen.

182/184: while (getline(filedata,128)) {...}

203/215/227: Code duplication, google: DRY-Prinzip

242: Du brauchst kein temporäres Objekt zu konstruieren, um es per push_back an den vector zu geben. push_back(tmp) reicht hier.

261/272: DRY

391/399/407: DRY

Das war das, was mir beim ersten Überfliegen so aufgefallen ist. Die Fehler bzw. der schlechte Stil wiederholen sich an zig Stellen.

Überleg mal, ob du das, was deine parse-Funktion machen soll, in wenigen Schritten (schaffst du es unter 10?) beschreiben kannst. Das ist dann Grundlage für eine Funktion. Die einzelnen Schritte sind jeweils wieder eine Funktion, die du in unterschritte aufteilst usw.

[cooky451]

pumuckl schrieb:

cooky451 schrieb:

9: globales namespace std;

Ist in dem Fall kein Problem.

Ich wollte noch etwas zur Aufteilung in Dateien schreiben, aber als ich dann nach unten gescrollt habe, habe ich zu viel Angst bekommen.

[camper]

gcc schrieb:

test.cpp: In function ‘void parse(char*)’:
test.cpp:420:116: warning: operation on ‘iCounter’ may be undefined

hm...

sstr << "\t\t\t*MESH_TFACE " << i << "\t" << iCounter++ << "\t" << iCounter++ << "\t" << iCounter++ << endl;

Da hat er recht.

[volkard]

Ich glaube, Du solltest ein halbes Jahr keine Spieleprogrammierung betreiben und keine Programmierung mit grafischer Oberfläche. Wenn man konkret dieses gerade anliegende Problem durchboxen will, hat man keine Freiheit, über die anderen mindestens vier Möglichkeiten nachzudenken. Lieber erstmal unwichtige Spaßprogrammierung betreiben, aber dafür nach jeder Funktion zweimal überlegen, ob man das nicht so machen könnte, daß man keinen Code doppelt hat und daß man den Code in fünf Jahren (oder als Abkürzung nach einer Flasche Rum, wer ihn verträgt) noch flüssig lesen und verstehen kann. Dadurch verbessert man sich Funktion für Funktion in Hinsicht auf Lesbarkeit. Und das ist gleichermaßen Fehlerfindbarkeit und Fehlergarnichthinschreibbarkeit. Fehler sind teuer. Teuer. Ohne auf konstruierte Beispiele von herunterfallenden Raumkapseln herumzureiten oder auf unzufriedenen Kunden oder Chefs, allein alleine ist es viel geiler, (zwar langsam) Code zu schreiben, der klappt, als (kaum doppelt so schnell) Code zu schreiben, der nicht klappt (und die Fehlersuche dauert zehnmal so lang und ist zehnmal so ätzend, macht zusammen hundertmal so viel Ärger, so isses!). Damit kannste die ersten 5 bis 7 Jahre auf 12 Monate stauchen (Mit viel Buch und keinem Feiertag).

Aber Achtung! Viele C++-Programmierer fallen in einen Technik-Rausch. Die machen dann Fibinaccizahlen als Template-Metaprogrammierung und so. Und bald ist ihr einziges Sinnen, C++ auszureizen. Das darf nicht passieren. Du würdest schlimmstenfalls 10 Jahre verlieren, die Du in der Sucht verbringst. Ohja, es macht Spaß. Aber das Problem hast Du ja nicht. Nach einem halben Jahr geh zurück zum GameCoding, was Du ja eigentlich willst. Die holen Dich da wieder raus. Und Du kannst ihnen im Gegenzug C++ beibringen.

[seux]

Ich betreibe keine Spieleprogrammierung. Ich hab bisher immer ein bisschen in meiner Freizeit von der Schule programmiert. Ist sozusagen eins meiner Hobbies. Dennoch versuch ich mich noch nicht auf eine Sache direkt zu beschränken. Dieses Beispiel jetzt war zwar direkt zur Spieleentwicklung, jedoch eher um Models vom 3D Programm nach UDK zu transportieren. Also nicht wirklich direkt was mit der Spieleprogrammierung.
Und ein halbes Jahr lang mal eben nicht zu programmieren geht nicht. Für mich hat grad das Studium begonnen. Da muss ich programmieren...

[Gast]

volkard schrieb:

Aber Achtung! Viele C++-Programmierer fallen in einen Technik-Rausch. Die machen dann Fibinaccizahlen als Template-Metaprogrammierung und so. Und bald ist ihr einziges Sinnen, C++ auszureizen. Das darf nicht passieren.

Auf den Punkt gebracht.

[pumuckl]

seux schrieb:

Und ein halbes Jahr lang mal eben nicht zu programmieren geht nicht.

Niemand hat geschrieben dass du ein halbes Jahr lang nicht progrmmieren sollst. volkard hat geschrieben, dass du erstmal mit den basics anfangen sollst, also erstmal isolierte kleinere Probleme lösen, um "Schreiben" zu lernen.

[C++ von AbisZ Nichtkenner]

Ich kenn jetzt C++ von A bis Z nicht. Hab schon oft versucht, in Bücherläden reinzuschnuppern, aber immer waren alle Bücher eingeschweißt...
Letzens hab ich aber seinen "Grundkurs C++" in den FIngern gehabt.
Thema Operatorüberladung:
* op+ als Member, nicht freie Funktion. Verändert überdies "this"!
* op++ arbeitet auf einem static member!
* operator<< verwendet cout, nicht den übergebenen ostream. Außerdem gibts keinen return. Der operator<< wird dann durch ein cout in main "getestet"
* operator>> verwendet den übergebenen istream nicht, macht etwas mit cout (!), und auch hier fehlt ein return...

Das hat mir dann erstmal gereicht. Auf die überall angegebenen "bonus-seite" kann man nur mit dem Code im Buch zugreifen, auf seiner Homepage findet man gar nichts zu dem Buch. Hätte mich jetzt schon interessiert.

Wenn nun "C++ von A bis Z" ähnliche Spielchen treibt - gute Nacht!

[asc]

seux schrieb:

Immerhin programmier ich nun doch schon etwas länger und mir hat noch nie jemand gesagt, das ich nen schlechten Stil hätte (also weder mein Informatik Lehrer im Abitur...

Ich habe bislang nur einen Lehrer (genauer Dozent an einer FH) erlebt, der einen guten Programmierstil hatte. So traurig ich das auch finde, viele Lehrer ruhen sich auf dem einmal gelernten aus. Und gerade C++ und die Informatik allgemein haben sich in den letzen 15 Jahren massiv gewandelt.

[asc]

C++ von AbisZ Nichtkenner schrieb:

Ich kenn jetzt C++ von A bis Z nicht. Hab schon oft versucht, in Bücherläden reinzuschnuppern, aber immer waren alle Bücher eingeschweißt...
Letzens hab ich aber seinen "Grundkurs C++" in den FIngern gehabt.

Ich habe selbst nur Auszüge aus dem Buch lesen können (inzwischen zeigt google-Books leider hier garnichts mehr an), und alleine die waren schlimm. Und der Grundkurs C++ soll sogar besser sein...

[Helmut.Jakoby]

Beim überfliegen Deines Codes ist mir am meisten der "prozedurale Programmierstiel" aufgefallen. Die Klassen sind ausschließlich Strukturen mit ctor.
Evtl. hilft Dir die Beschäftigung mit dem objektorientierten Paradigma; erst wenn man dieses verinnerlicht hat, kann man die Vorzüge von C++ nutzen.
Gruß

[pumuckl]

Helmut.Jakoby schrieb:

Beim überfliegen Deines Codes ist mir am meisten der "prozedurale Programmierstiel" aufgefallen. Die Klassen sind ausschließlich Strukturen mit ctor.
Evtl. hilft Dir die Beschäftigung mit dem objektorientierten Paradigma; erst wenn man dieses verinnerlicht hat, kann man die Vorzüge von C++ nutzen.
Gruß

Stimmt zwar so nicht, man kann C++ durchaus auch wunderbar prozedural programmieren und muss nicht immer alles zwangsläufig in Klassen packen, allerdings bietet OOP hier durchaus einige Vorteile.

[Helmut.Jakoby]

pumuckl schrieb:

Helmut.Jakoby schrieb:
Beim überfliegen Deines Codes ist mir am meisten der "prozedurale Programmierstiel" aufgefallen. Die Klassen sind ausschließlich Strukturen mit ctor.
Evtl. hilft Dir die Beschäftigung mit dem objektorientierten Paradigma; erst wenn man dieses verinnerlicht hat, kann man die Vorzüge von C++ nutzen.
Gruß

Stimmt zwar so nicht, man kann C++ durchaus auch wunderbar prozedural programmieren und muss nicht immer alles zwangsläufig in Klassen packen, allerdings bietet OOP hier durchaus einige Vorteile.

Hast natürlich recht, aber ich kam beim überfliegen des Codes durch die große Funktion 'parse' drauf.
Hatte durch die Kommentare so das Gefühl, das die einzelnen Aktionen wie Einlesen der Daten aus Strings etc. durch die einzelnen Klassen ggf. selbst erledigen werden könnte. Dann wäre das ganze evtl. schon mal 'verteilter' in den dann zuständigen Klassen.
Gruß