Mit den C-Klammercasts wird auf irgendeine Weise versucht, etwas umzuwandeln. Bestenfalls wird eine Standardkonvertierung angewendet (was in C++ dem static_cast entsprechen würde),
Nein, das stimmt nicht. Ein C-Cast hat gar nicht die Möglichkeit
auf irgendeine Weise Casts vor zu nehmen
Ich denke, du weisst, was ich damit gemeint habe (mal abgesehen davon, dass ich geschrieben habe, "es wird versucht"). :roll:
Da ein static_cast<> so ziemlich die Selben Möglichkeiten hat wie ein C-Cast (mit Ausnahme des entfernen der Konstanz/volatileness eines Ausdrucks) ist das Verhalten mehr oder weniger austauschbar, wenn die Kontanz/volatileness keine all zu wichtige Rolle spielt.
Das ist völlig falsch. Erstens mal ist gerade die Funktion des reinterpret_cast auch im C-Cast enthalten. Man kann also zum Beispiel Folgendes schreiben, was mit static_cast nicht geht:
|
C-/C++-Quelltext
|
1
2
|
int* p;
int i = (int)p;
|
Zweitens ist es
eben gerade nicht austauschbar, und zwar weil CV-Correctness in C++ eine wichtige Bedeutung hat und weil man sich mit C-Casts Dinge angewöhnt, die fehleranfällig sind. Wenn man in "harmlosen" Ausdrücken klammercastet, wird man auch nicht so schnell erkennen, wann etwas "gefährlich" ist. Und wieso nicht von Anfang an die sichere Variante lernen?
Mit reinterpret_cast sagt man ausdrücklich, dass man Gewalt anwendet.
Genau, und diese "Gewalt" ist unsicher. Egal ob mit C-Cast oder reinterpret_cast. Letzterer muss nämlich ebenfalls keinen Fehlerbericht rausgeben, sondern castet fröhlich
Alles in
Alles. Dazu ist das Ergebnis von reinterpret_cast<> implementationsabhängig, ergo nicht (oder selten) portabel.
Ja, aber im Gegensatz zu C-Casts weiss man bei reinterpret_cast, dass Gewalt angewendet wird, während C-Casts alles bedeuten können. Dass das Resultat undefiniert sein kann, stimmt zwar, ist aber bei C-Casts nicht anders. Und um wie du alles wörtlich zu nehmen: "alles in alles" stimmt ebenfalls nicht. reinterpret_cast kann weniger als C-Casts und ist auf die gefährlichen Einsatzbereiche spezialisiert. Er kann nämlich das, was static_cast und const_cast können, nicht.
Schlimmer ist es jedoch, wenn man die Funktionalität eines static_cast will, aber den Klammercast anwendet - man erfährt unter Umständen gar nicht, dass keine Standardkonvertierung dazu existiert.
Sollte der Fall mal eintreten erfährst du das sowiso nicht, zumindest nicht beim Casten (ob der Compiler zur compilierzeit Warnungen ausspuckt liegt bei ihm).
Wiederum falsch. Mit static_cast geht beispielsweise oben genanntes Codebeispiel nicht, ohne zur Compilezeit einen Fehler zu erhalten:
|
C-/C++-Quelltext
|
1
2
|
int* p;
int i = static_cast<int>(p);
|
Oder das:
|
C-/C++-Quelltext
|
1
2
|
const int c = func(); // func() gibt einen int zurück - um Compiler-Optimierung zu umgehen
int& d = static_cast<int&>(c);
|
Mit Klammercast gehen übrigens beide - ohne jegliche Warnung.
Ich kann ehrlich gesagt nicht ganz verstehen, wieso du dich so stur gegen die C++-Operatoren wehrst, zumal aus meiner Sicht bereits Erkennbarkeit für sie sprechen sollte. Wirklich Argumente gegen sie hast du ja keine gebracht.