Kaeru Gaman hat geschrieben:aber im Endeffekt ist es doch mehr oder weniger kosmetisch, und es gibt so viel wichtigeres was noch getan werden muss...
Ich halte das ehrlich gesagt nicht für kosmetisch, es sorgt einfach für sichereren Code, wenn der Compiler erkennt, daß Du etwas tust, was eigentlich nicht in Ordnung ist.
Als Beispiel mal ein kleiner PB-Code:
Code: Alles auswählen
Structure TEST
name$
id.l
EndStructure
Structure FEST
x.l
y.l
name$
EndStructure
Procedure theProc(*obj.FEST)
MessageRequester("name$", *obj\name$)
MessageRequester("x", Str(*obj\x))
MessageRequester("y", Str(*obj\y))
EndProcedure
something.TEST
something\name$ = "something"
theProc(something)
Wie Du siehst, wird hier in der Procedure eine Variable vom Typ "FEST" erwartet, aber es wird einen vom Typ "TEST" übergeben. Der Compiler meckert
nicht. Du kannst das Programm sogar ausführen, es wird zwar seltsame Werte ausgeben, aber viel Spaß dann bei der Fehlersuche. Vor allem, wenn das Projekt sehr groß ist und mehrere Leute dran gearbeitet haben! Und was die Sache bzgl. PB noch krasser macht, ist, daß es hier nichtmal um einen simplen Datentyp geht, der einfach nur ein Alias hat, sondern hier geht es sogar um zwei Strukturen!
Der C/C++ Compiler würde dagegen sofort meckern. Selbst wenn beide Variablen einfache Integer wären, die einfach nur per Typedef zu verschiedenen Typen gemacht wurden (also genau das, worum es bei Fluids Kommentaren ging), würde der Compiler zumindest eine Warning ausgeben.
Das heißt, Du würdest eine solche potenzielle Fehlerquelle sehr schnell entdecken, am besten noch bevor Du überhaupt was vom Fehler mitkriegst (weil Du ja die Warnings siehst und die Stellen direkt in Ordnung bringen kannst, bevor Du das Programm testest).
Und nun kann es ja sein, daß jemand so etwas absichtlich machen möchte. Zum Beispiel, wenn es sich wirklich nur um simple Datentypen handelt. In diesem Fall kann er casten, und das ist der Grund, warum in dem C++ Codebeispiel so viele Klammern sind. Weil explizit gesagt wird "Hallo Compiler, ich will hier gern ein
HWND an eine Funktion übergeben, die eigentlich einen
unsigned int verlangt. Ich weiß was ich tue, also werde ich hier casten, Du weißt also Bescheid."
Somit wird der Compiler auch keine Warning mehr ausgeben. Aber der Programmierer muß eben ausdrücklich vermerken, daß dieser Cast gewollt ist.
Ihr müßt bei einem großen Projekt auch immer im Hinterkopf behalten, daß es sehr gut sein kann, daß ein Fehler nicht von dem Programmierer bemerkt wird, der ihn verursacht hat, sondern von einem anderen aus dem Team, der gar nicht weiß, woran der Verursacher gerade gefummelt hat. Wenn er nun das Projekt kompiliert, und der Compiler ihm gleich mal ein paar Warnings um die Ohren haut, dann hat er wenigstens schonmal einen gewaltigen Vorteil beim Debuggen. Wenn aber alles scheinbar super kompiliert, dann weiß er beim Entdecken der Fehlfunktion erstmal nicht, ob es sich um solch einen Programmierfehler handelt, oder ob es z.B. eher ein logischer Fehler ist (z.B. daß irgendeine Berechnungsformel falsch ist oder daß bestimmte Funktionen nie oder in falscher Reihenfolge aufgerufen werden).
Es gibt nunmal Fehler, die gleich beim Kompilieren erkannt werden können, und das sollten sie auch, denn Laufzeitfehler sind oft schwer zu finden. Ihr beschwert euch ja auch nicht drüber, daß PB meckert, wenn man eine undeklarierte Konstante verwendet. Man könnte ja auch sagen "so ein Quatsch, dann soll er die halt einfach mit 0 vorbelegen."
Zu guter Letzt: Ich sage ja nicht, daß PB das unbedingt braucht. Ich finde es nur nicht okay, zu sagen, daß das völlig überflüssig ist, nur um mal wieder C++ in ein schlechtes Licht zu rücken ("da gibt's ja für jeden Scheiß Klammern").
EDIT: Aber daß PB im obigen Beispiel stillschweigend kompiliert,
das finde ich schon sehr bedenklich. Typedefs hin oder her, das da oben ist eigentlich ein höchst fragwürdiges Verhalten.
