Fragen zum Casten
-
_matze schrieb:
Daher wird er ja auch immer als kritisch und zu Fehlern verleitend angesehen. Halte ich persönlich aber für Quatsch... (gleich gehts wieder los
das musst im c++ forum schreiben, wenn du 'nen flamewar provozieren willst. ich bin jedenfalls auf deiner seite.
-
+fricky schrieb:
das musst im c++ forum schreiben, wenn du 'nen flamewar provozieren willst.
Nee danke, nicht schon wieder...
-
Tim schrieb:
LukasBanana schrieb:
Ich kenne als aus dem reinen ANSI C nur folgende:
(int)x; // oder ... int(x);Der zweite geht in C shon nicht mehr.
was heisst 'schon'? ging das mal (in der k&r-ursprungsversion oder so)?
sieht aus wie ein funktionsaufruf. ich hab 'nen cast in der form jedenfalls noch nie gesehen.
-
+fricky schrieb:
sieht aus wie ein funktionsaufruf. ich hab 'nen cast in der form jedenfalls noch nie gesehen.
anderes baustelle. in c++ gibts das.
-
Ich hab den schon gesehen. In einem C++-Anfänger-Buch (weiß grad nicht, wie's heißt). Wäre für Umsteiger von anderen Sprachen auch ganz nett, da die vielleicht eher Umwandlungsfunktionen gewöhnt sind.
EDIT: Ach so, in C++ gehts. Hm...
-
volkard schrieb:
+fricky schrieb:
sieht aus wie ein funktionsaufruf. ich hab 'nen cast in der form jedenfalls noch nie gesehen.
anderes baustelle. in c++ gibts das.
huch? ich dachte in c++ haben casts diese form: blah_cast<typ>(blubb)
-
+fricky schrieb:
huch? ich dachte in c++ haben casts diese form: blah_cast<typ>(blubb)
nee.
<c++ mode on>
der üblichste ist double(5)+3, was bei eingebauten typen gleichbedeutend mit (double)5+3 ist. die funktionsstilsyntax macht die sache harmonischer zusammenpassend mit konstruktoraufrufen wie string("hallo")+"welt";. die anderen (const_cast<typ>(blubb) static_cast<typ>(blubb) dynamic_cast<typ>(blubb) reinterpret_cast<typ>(blubb)) sind in der tat absichtlich so gemacht worden, daß die verwendung augenkrebs erzeugt und der benutzer sie meidet. klappt aber nicht, viele n00bs hauen ihren code mit static_cast voll, wo er völlig nutzlos ist ( srand(static_cast<int>(time(NULL))); ).
<c++ mode off>
-
volkard schrieb:
die funktionsstilsyntax macht die sache harmonischer zusammenpassend mit konstruktoraufrufen wie string("hallo")+"welt";.
ja, funktionssyntax sieht eigentlich nicht schlecht aus. könnte man drüber streiten, ob man casts von funktionsaufrufen unterscheiden sollte, oder nicht.
volkard schrieb:
die anderen (const_cast<typ>(blubb) static_cast<typ>(blubb) dynamic_cast<typ>(blubb) reinterpret_cast<typ>(blubb)) sind in der tat absichtlich so gemacht worden, daß die verwendung augenkrebs erzeugt und der benutzer sie meidet.
naja, dann hätte man sie vielleicht besser ganz weglassen sollen. wie ich`s so sehe, hat c++ also 3 syntaktisch verschiedene typen von casts. das ist ja der wahnsinn.
-
+fricky schrieb:
naja, dann hätte man sie vielleicht besser ganz weglassen sollen. wie ich`s so sehe, hat c++ also 3 syntaktisch verschiedene typen von casts. das ist ja der wahnsinn.
Naja, eigentlich nicht so wahnsinnig wie es sich anhört. Denn, jeder cast hat seine eigene Aufgabe. Da wäre der static_cast<T>, der schon zur Compiletime überprüft, ob der cast möglich ist. Dies ist der am häufigsten benötigte cast und reicht für die meisten Anwendungsfälle absolut aus. Zusätzlich gibt es noch den dynamic_cast<T>, der für polymorphe Klassen zuständig ist. Er arbeitet zur Laufzeit, daher dynamic, und ermögicht es die Vererbungshierarchie rauf und runter zu casten. Der reinterpret_cast<T> ist wohl der stärkste und auch gefährlichste cast. Er wird wirklich nur in den seltesten Fällen benötigt, da er wirklich alles in alles casten kann ohne weitere Überprüfung. Naja der const_cast<T> macht halt das was er sagt: Er macht einen Wert konstant oder veränderbar. In C war das ja noch alles in einem Cast vereint und in C++ wird halt genau zwischen den verschiedenen Casts unterschieden. Daher die größere Anzahl.
-
^^ok, den sinn vom dynamic cast (wenn mir auch die schreibweise nicht so toll gefällt) sehe ich ein, aber die anderen sind ja redundant. der typ(x) z.b. könnte den rest erschlagen. naja, zum glück müssen wir C-coder uns nicht mit sowas rumärgern.
-
+fricky schrieb:
^^ok, den sinn vom dynamic cast (wenn mir auch die schreibweise nicht so toll gefällt) sehe ich ein, aber die anderen sind ja redundant. der typ(x) z.b. könnte den rest erschlagen. naja, zum glück müssen wir C-coder uns nicht mit sowas rumärgern.
Ist halt ein sicherheitsfeature. fuer sowas hat man ja streng typisierte sprachen
und meiden soll man die casts weil man damit das typsystem umgeht. und der augenkrebs ist deshalb praktisch, da eine umgehung des typsystems (ueber casts) sofort ersichtlich wird.
-
Shade Of Mine schrieb:
Ist halt ein sicherheitsfeature. fuer sowas hat man ja streng typisierte sprachen
welche sprachen meinst du? c und c++ sind nicht streng typisiert. man kann ja z.b. int nach char casten, oder, schlimmer noch, einen char* etwa in einen int*. in streng typisirten sprachen geht sowas nicht (zumindest nicht das letzte).
-
+fricky schrieb:
welche sprachen meinst du? c und c++ sind nicht streng typisiert. man kann ja z.b. int nach char casten, oder, schlimmer noch, einen char* etwa in einen int*. in streng typisirten sprachen geht sowas nicht (zumindest nicht das letzte).
Und jetzt denk mal darueber nach warum man deshalb die xxx_cast Sachen verwenden soll. Ein char* ist eben nicht in einen int* (implizit) konvertierbar - mit static_cast aber schon. Nur mit einem c-cast kannst du auch einen char in einen int* packen. Casts umgehen die strenge typisierung und deshalb ist eben augen krebs sehr sinnvoll.
-
Shade Of Mine schrieb:
Und jetzt denk mal darueber nach warum man deshalb die xxx_cast Sachen verwenden soll.
ist doch egal, was man soll. entscheidend ist, was möglich ist. in einer streng typisierten programmiersprache hat man keine möglichkeit, sich irgendwelchen unsinn hinzucasten.
-
Gate schrieb:
Der reinterpret_cast<T> ist wohl der stärkste und auch gefährlichste cast. Er wird wirklich nur in den seltesten Fällen benötigt
Wie meinen? Den benutze ich tagtäglich!
Es gibt durchaus Umgebungen, in denen das Reinterpretieren ständig notwendig ist. In meinem Fall ist es der Austausch von Zeigern mit LabView-Vi's. LabView kennt nunmal keine Zeiger, also wird ständig irgendein Zeiger nach long gecastet, und später wieder zurück. Allerdings bei uns mit C-Style-Casts, denn sonst nimmt das Augenkrebs-Phänomen ungeahnte Ausmaße an (und das unnötigerweise)...