spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »"FOGX"«

AFAIK ist C++ seit dem neuen Standard eine eigene Sprache.

Es war eines der Hauptziele bei dem Entwicklen von C++ dass C Programme mit möglichst geringen Änderungen weiterfunktionieren. Damit wurde auch den Managern vorgegaukelt, dass Ihre Mitarbeiter all Ihr Wissen weiternutzen können und das war wahrscheinlich der Hauptgrund für die weite Verbreitung. C läßt aber sehr viele gefährliche Konstrukte zu, das "=" in einem if haben wir ja hier erst vor kurzem gehabt. Damit C++ möglichst compatibel ist, lässt es fast alle gefährlichen Konstrtukte auch zu. Manche haben überhaupt keinen direkten Sinn, andere hatte damals einen Sinn als die Compilertechnolgie noch nicht so weit war und dadurch optimiert werden konnte.

Zitat

Man muss ja außerdem die C-Header nicht verwenden. Und wozu gibt's secure-Functions? Die wurden nicht grundlos in die Header gesetzt.

Ich spreche über die Sprache, nicht Header (die es ja bei vielen Sprachen gar nicht gibt) oder Libraries.

Ein heutiger Compiler wird daraus den gleichen Binärcode generieren wie wenn ich das


in eine extra Zeile schreibe und lesbarer finde ich Deinen Code auch nicht. Ich dachte aber tatsächlich an so etwas wie es Darkraider schrieb.

Und bei den gefährlichen Konstrukten geht es ja nicht um unser "rockt" uder "suckt" sondern u.U. um viele (hundert) Millionen von Dollars. So gab es z.B. schon vor längerem einen Absturz in einem C oder C++ Program wodurch das gesammte Telefonsystem auf einer der beiden US Küsten für Stunden zusammenbrach. Es ging um ein C, und daher auch C++ Konstrukt. Und dass



compiliert finde ich schon lächerlich und führt natürlich auch zu Programmfehlern.

Zitat von »"nix da"«

	C-/C++-Quelltext
1 2	if ((result = funktion (parameter)) != okay) mach_was ();

sowas meine ich.

Geht das?
Wußte ich noch nicht
Aber sieht etwas nett aus

Aber ich würde das mit dem result= eher vor die if anweisung bauen damit man etwas besser durchblickt

Aber wenns am ende eh das selbe tut dann kann mans auch so machen

Zitat von »"nix da"«

Ist für mich kein Grund Platz zu verschwenden und dadurch schnell unübersichtlich Code zu bekommen.

Das war ein Grund als 800x600 Pixel und 15 Zoll Monitore State of the Art waren.

Zitat von »"Osram"«

Liegt daran das viele Programme so schlampig gecodet sind wie das US Stromnetz aufgebaut ist. Das hat mit der Programmiersprache wenig zu tun, wenn der Entwickler zu blöde ist etwas richtig zu machen.

Nein, z.B. mit Eiffel konnte man den Fehler nicht machen, da es das Konstrukt erst gar nicht gab. Wie der Eiffel Entwickler Meyer schrieb "Das Problem an C/C++ ist nicht was es nicht kann, sondern was es kann".

Zitat von »"Osram"«

Du arbeitest irgendwie erheblich zu wenig mit Pointern und Funktionspointer, dann wüsstest Du was es damit auf sich hat.

Natürlich weiss ich warum es compiliert - und das bestärkt mich darin, es schlecht zu finden. Es ist einfach ein Folge von mehreren Regeln, von denen Funktionspointer eine sind. Funktionspointer kann man auch sinnvoll einsetzen. Aber so eine Zeile wie oben hat nie einen Sinn, da kann ich genausogut einfach ";" (die leere Anweisung) schreiben.

Zitat von »"nix da"«

Zitat von »"Osram"«

Natürlich weiss ich warum es compiliert - und das bestärkt mich darin, es schlecht zu finden. Es ist einfach ein Folge von mehreren Regeln, von denen Funktionspointer eine sind. Funktionspointer kann man auch sinnvoll einsetzen. Aber so eine Zeile wie oben hat nie einen Sinn, da kann ich genausogut einfach ";" (die leere Anweisung) schreiben.

Eine Funktion ist nichts anderes als ein Pointer. Wo wäre der Sinn Funktion von Pointer zu unterscheiden? Nur weil es einen Operator () gibt, dem man N Parameter geben kann?


Ich seh da keinerlei Nachteile. Hier greift eher wieder die Dummheit der Entwickler.

Wenn eine Sprache einen Fehler zulässt den andere nicht zulassen, ist das ein gravierender Nachteil. Mit dem Argument "dann muss der Programmierer halt besser sein" kann ich alle Haken an einer Sprache begründen. Dann können wir auch wieder 100% in Assembler schreiben. Man muss Variablen selber verwalten? Das macht ein guter Programmierer mit links. Dauert länger was zu schreiben? Ein guter Programmierer ist 100-1000 mal schneller als ein Durchschnittlicher der fängt das wieder auf. Ist sehr Fehleranfällig? Dann darf der Programmierer halt keine Fehler machen.

In Wirklichkeit macht aber jeder Mensch ab und zu Fehler. Er muss oft im Crunch übermüdet programmieren, wird von anderen Codern/Modellern etc abgelenkt, hat mal Kopfschmerzen oder einfach einen schlechten Tag, hat gerade vorher etwas in einer anderen Sprache machen müssen, denkt noch an die Frau von gestern oder an die Funktion in der er die Funktion aufruft, die er gerade schreibt oder hat halt ganz einfach mal einen "Blackout". Wenn man z.B. eine Million Code Zeilen in seinem Leben schreibt, dann macht man wirklich fast jeden möglichen Fehler mal in irgendeiner Zeile. Und dann ist halt der entscheidende Unterschied ob Dein Tool das zu Compilezeit merkt oder der Fehler erst zur Laufzeit auftritt. Also entweder:

Du machst den Fehler, codest noch 5 Min weiter.
Du versuchst zu compilieren, siehst die Warnung oder Fehlermeldung < 5 Min
der Fehler ist ja wirklich offensichtlich wenn man drauf hingewiesen wird und auch sofort behoben indem man halt das "()" hinzufügt 1 Min

oder aber

Du machst den Fehler, codest noch 5 Min weiter.
Du compilierst, keine Warnung oder Fehlermeldung < 5
Sagen wir durch einen - nicht wirklich unwahrscheinlichen - Zufalll ist der Fehler etwas versteckt und wird beim Testen nicht gesehen.
Zwei Monate später tritt er beim Kunden auf. Nachdem der Support Ihm icht helfen kann (scheinbar kein Bedienerfehler) wirst Du mit Ihm verbunden. Der Kunde erwartet natürlich dass aus seiner Fehlerbeschreibung "Es geht halt nicht!" sofort den Fehler erkennst. Du musst Ihn durch Fragen weiter verärgern (er denkt dass ist nur ne blöde Ablenke vom Fehler). Du holst seine Daten und Konfiguration, lässt auch andere testen und 4 Arbeitsstunden später hast Du es endlich reproduzierbar auf Deinem Rechner und hast genau ausprobiert, was die Voraussetzungen sind. Du erinnerst Dich dumpf dass Du an dem Feature gearbeitet hast. Nach 30 Minuten hast Du in der Versionenkontrolle die damalige Änderung gefunden, die Unterschiede zur Version davor für jede betroffene Datei angesehen und den Fehler gefunden. Beheben kostet dann eine Minute. Kurz getestet und die Änderung in die Source Kontrolle eingecheckt (5 Min). Beim Support - der kennt die Kundenwünsche angerufen und abgecheckt wie wichtig dieser Fehler für die Kunden ist. Er tritt zwar nur unter ganz bestimmten Umständen, also relativ selten auf, aber Ihr seht kein Workaround und die Kunden vor dem Fehler warnen ist genauso blöde wie eine neue version machen. Weitere 20 Minuten weg. Also neue Version gemacht (Versionsnummer hoch, geschaut was anderes sich angesammelt hat, in Versionenkontrolle einchecken, super kurze Readme schreiben, auf FTP schieben, tester benachrichtigen) 10 Minuten. Ab jetzt ist es "nur" noch zeit der tester und dann des Supports, der es für die Kunden zur Verfügung stellt.

Fazit - Version B hat in diesem Fall 30 mal mehr Zeit gekostet. Ausserdem ist der Kunde verärgert.

Für mich ist dieser Unterschied so riesengross dass ich bei den Tools für unsere Datenanleger nach dem selben Schema vorgehe. Das eine Tool hat eine "Alles Checken" Funktion und das andere eine Behandlung für Warnungen und Fehlermeldungen wie ein guter Compiler - Beim "Compilieren" unserer 3D Objekte werden die Fehler in eine Liste aufgenommen etc, ein Doppelclick auf einen Eintrag springt zu dem kritischen Objekt etc. Mal ne Warnung zu ignorieren oder unterdrücken kostet keine Minute, aber jeder Fehler der zum Kunden geht das zig-fache und verärgert den.

Und Spiele sind so anders ja auch nicht - Fehler im Program verärgern natürlich, testen ist nie zu 100% möglich (auch nicht mit Coverage Tools, selbst wenn sie helfen), Fehlermeldungen der Kunden zu behandeln kostet Zeit, ca 1/3 bei uns ist von Bedienerfehlern, oft enthalten sie gar keine Info (gerade vor ein paar Tagen hat einer nicht mal gesagt mit welchen Spielen er ein probelm hat, sondern nur dass er irgend ein Problem hat und wir Ihm helfen sollen), eine neue Version hat einen relativ grossen Overhead (wenn auch aus leicht unterschiedlichen Gründen), es gibt zig Situationen in denen Du selbst eine gute Fehlermeldung mit Logdateien und exakter Beschreibung nicht reproduzieren kannst etc.