🚀 go-pugleaf

Hi,
Ullrich von Bassewitz (uz@wuschel.ibb.schwaben.com) wrote:
: Dietmar Kuehl (kuehl@uzwil.informatik.uni-konstanz.de) wrote:
: > Der Fehler ist (eigentlich) ein Syntaxfehler, da der Compiler
: > "weiss", dass String-Literal eigentlich 'const' sind und nur aus
: > historischen Gruenden als 'non-const' angesehen werden. Der Compiler
: > kann bereits beim Uebersetzen sehen, dass da was im argen ist.

: Wie soll er das machen? Beispiel:

:     void Clear (char* S)
:     {
:         *S = '\0';
:     }

:     int main ()
:     {
:         Clear ("Lalle");

Nichts hindert den Compiler daran, DIESEN Aufruf als kritisch anzusehen
und eine Warnung auszuspucken! ... der Compiler WEISS, dass DIESER
Aufruf Gefahren in sich birgt. Sicher, wenn 'Clear()' den String nicht
aendert, wird eine Warnung zuviel ausgegeben. Der beste Weg, diese
Warnung zu verhindern ist allerdings 'Clear()' zu aendern. In Deinem
Beispiel kann man die Deklaration von 'Clear()' nicht aendern und man
sieht also direkt, dass da was faul ist ("undefined behavior" lauert in
diesem Fall in der Funktion 'Clear()').

Nun koennte man behaupten, "Ich kann die Deklaration von 'Clear()' aber
nicht aendern (weil sie aus einer Bibliothek von sonstwo kommt)". Das
ist aber falsch! Wenn 'Clear()' tatsaechlich den String nicht aendert
(und das sollte man tunlichst ueberpruefen, bevor man das macht, was
ich gleich vorschlage!) und es also tatsaechlich sinnvoll ist, ein
String-Literal zu uebergeben, dann kann man die Funktion ueberladen,
z.B. mit dieser:

     void Clear(char const *str)
     {
       Clear(const_cast<char*>(str));
       // falls 'const_cast' noch nicht unterstuetzt wird, tut es
       // folgendes ganz genauso:
       // Clear((char*)str);
       // Allerdings ist 'const_cast' unbedingt vorzuziehen (siehe
       // "More Effective C++" Item 2).
     }

Das ist alles wunderschoen und portable, solang die Funktion wirklich
nicht den String aendert.

:         return 0;
:     }

: Das Problem ist also nicht, dass es ein Syntaxfehler ist, sondern es ist
: wirklich ein Problem der Definition von String-Literalen als non-const.
: Solange das nicht geaendert wird gibt es fuer den Compiler keine
: Moeglichkeit etwas zu tun (zumindest in den meisten Faellen nicht).

Das sehe ich anders... (siehe oben). Man kann den Compiler einfach
vorsichtiger als noetig sein lassen und ein paar Warnungen zuviel geben
lassen. Da man die zuviel Warnung wieder umgehen kann (siehe oben) ist
das genau das, was man will. Der gcc unterstuetzt das sogar (mit der
Option '-Wwrite-strings', die, wie ich schon sagte, leider nicht in
'-Wall' oder der Default-Setzung enthalten ist). Man muss ich uebrigens
klar machen, dass der Code in Deinem Beispiel "undefined behavior"
produziert, also z.B.  das Programm mit einen Segmentation-Fault
abbricht ("abstruerzt"). Das ist schlichtweg katastrophal! Also MUSS
man was dagegen tun, dass sowas passiert.  Es ist um so schlimmer, dass
es Compiler gibt, die dafuer Code generieren, bei dem das Programm
NICHT abstuerzt: Wenn man mit einem solchen Compiler entwickelt und es
aber mit einem anderen Compiler irgendwo installiert, treten ggf.
Fehler auf, die beim Testing nicht auftreten konnten! Gruselig. Man
stelle sich vor, der Code wird im Autopilot eines Flugzeugs verwendet!
Da will ich nicht einsteigen: Programmabsturz koennte u.U. mit
Flugzeugabsturz einhergehen... (OK, die werden vermutlich den Code, der
im Flugzeug laeuft mit dem selben Compiler uebersetzen, mit dem sie
testen. Aber man kann ja nie wissen....).
--
dietmar.kuehl@uni-konstanz.de
http://www.informatik.uni-konstanz.de/~kuehl
I am a realistic optimist - that's why I appear to be slightly pessimistic