S
Original erstellt von Solaris'dUKe:
**Und was nützen dir null-initialierte Variabeln beim Enwickeln, wenn ein Fehler im Code beim Release dafür ein Crash ergibt ?
**
sie werden eben nicht mit 0 initialisiert, sondern mit einem ungültigen wert. somit führt jeder zugriff auf den zeiger zu einem absturz - debugging ist erleichtert.
bzw. kann mich mein compiler warnen, dass ich den zeiger vor seiner initialisierung verwende.
Sicher, wenn ich alle 0-Zeiger abfange dann stürtzt das programm nicht ab, aber das verhalten kann anders als erwartet sein:
char* text=0;
...
getWindowText(text); //diese funktion test auf 0
writeToIrgendwas(text); //test auch auf 0
ausgabe ist somit nix.
und jetzt finde so einen fehler mal...
da hab ichs doch lieber wenn ich nen absturz bekomme der mir sagt:
in getWindowText gibts nen zugriff auf nen ungültigen zeiger.
dann mache ich n backtrace und sehe dass exakt hier getWindowText mit ungültigen Zeiger aufgerufen wurde.
wenn du jetzt meinst: man kann ja immer
assert(p);
schreiben:
ja, kann man.
aber wozu? mein compiler macht das für mich.
OK, man kann mit pre- und postconditions arbeiten:
void getWindowText(char* buf)
{
precondtion(buf!=0);
//...
postcondition(strlen(buf)>1);
}
dann würden diese 'assert' ja sinn machen.
aber in diesem fall ist ja ein ganz anderer stil gefrag (design by contract)
ausserdem gibts ja nix daran auszusetzen
assert(0); zusätzlich noch zu schreiben - warum auch nicht. ist zwar redunant, aber immer noch besser als ein
if(!p) return;
letzteres kommt leider öfters vor (und dieses p kann 0 sein verleitet ja dazu)