static_cast vs. alten cast-operator



  • Jester schrieb:

    Dann versuch mal casts zu finden.

    hat das eigentlich schonmal irgendjemand wirklich getan?



  • Redhead schrieb:

    Das stimmt nicht so.
    Der "alte" cast

    (double) ...
    

    entspricht dem neuen cast

    reinterpret_cast<double> ...
    

    das stimmt leider nicht, der alte cast entspricht den 4 c++ casts, dabei

    von z.b. const int auf int

    (int)i;
    const_cast<int>(i);
    

    beim umwandeln von pointern (neu interpretierung ihrers zeigertyps) von z.b. float* auf int*

    (int*)p;
    reinterpret_cast<int*>(p);
    

    beim umwandeln der daten von z.b. float zu int

    (int)d;
    static_cast<int>(d);
    

    und beim specialisieren von objectpointern von z.b. frucht* zu apfel*

    (apfel*)pChild;
    dynamic_cast<apfel*>pChild;
    

    wie man sehen kann, kann man mittels c casts "alles auf alles" casten und bei c++ gibt es nicht möglich, so kann man also nicht aus versehen von z.b. const char* auf unsigned char* mittels reinterpret_cast casten, weil reinterpret_cast nicht das const vom datentypen entfernen kann, was jemandem mit c eventuell passieren könnte.

    dazu kann man sich eventuell merken, dass const_cast und reinterpet_cast am schnellsten sind, da sie nur zur compilezeit die vom compiler angenommenen type von daten modifizieren, static_cast convertiert zur laufzeit daten, z.b. von float zu int, das kann je nach system schon ein wenig aufwendig sein, bei dynamic_cast wird es dann sehr langsam, weil mittels RTTI typen bestimmt werden müssen und eventuell exception werfen/fangen.

    rapso->greets();



  • DrGreenthumb schrieb:

    Jester schrieb:

    Dann versuch mal casts zu finden.

    hat das eigentlich schonmal irgendjemand wirklich getan?

    Hab ich mich auch schon gefragt - oft gelesen, nie gebraucht.
    Aber zumindest springen einem C++-Casts sofort ins Auge...



  • @rapso: dynamic_cast nicht.



  • rapso schrieb:

    so kann man also nicht aus versehen von z.b. const char* auf unsigned char* mittels reinterpret_cast casten, weil reinterpret_cast nicht das const vom datentypen entfernen kann,

    War es nicht so, das der reinterpret_cast eigentlich der "grenzenlose C-Cast ersatz" ist und die anderen aber den von dir genannten Einschränkungen unterliegen?



  • Jester schrieb:

    Dann versuch mal casts zu finden. Also im Editor Ctrl-f und dann Suchbegriff eingeben. static_cast ist da deutlich netter.

    das ließe sich zu einem vorteil für static_cast auswerten, *falls* es notwenig wäre nach casts zu suchen. isses aber nicht.

    Viel wichtiger ist aber: static_casr kann garnicht alles. Es kann nur verwandte Typen ineinander umwandeln. Du kannst damit zum Beispiel nicht aus Versehen ein const wegcasten oder einen int in nen Pointer verwandeln und solche Sachen.

    punkt für static_cast.

    außerdem ist static_cast eklig zu schreiben. absichtlich, damit man es nicht so gerne verwendet. also verwende ich es nicht gerne. und beim lesen erweckt so ein cast gleich viel ausmerksamkeit. beim fehlersuchen schaut man sofort beim cast. das ist zu viel aufmerksamkeit für ne einfache konvertierung vin int nach double.

    static_cast soll doch eher für die harte brocken verwendet werden. nämlich downcasts in der klassenhierarchie, wenn durch weiteren code sichergrestellt ist, daß dynanic_cast gar nicht nötig ist.

    kennste
    foo(string("hallo")+" welt");
    ?
    string("hallo") ist die normale schreibweise, um was zu casten. man ruft den entsprechenden typumwandlungskonstruktor auf. entsprechend müßte auch double(7) normal sein.

    wenn du anfängst, static_cast<string>("hallo") zu schreiben, überlege ich mir, ob ich static_cast<double>(int) schreibe. solange du damit nicht anfängst, widerspreche ich euch allen.



  • Dieser Thread wurde von Moderator/in kingruedi aus dem Forum Rund um die Programmierung in das Forum C++ verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.



  • volkard schrieb:

    string("hallo")

    sorry, kurz Offtopic wo ich das hier gerade sehe.
    sollte ich string eher so wie oben definieren, oder besser string = "hallo"?



  • Ist total egal.



  • sollte ich string eher so wie oben definieren, oder besser string = "hallo"?

    Ja

    string myStr = "hallo"; //Konstruktoraufruf + op=
    string myStr("hallo"); //nur ctor
    

    Zurück zum Thema : ich nehme bei POD typen nach wie vor die "alten" C-casts. static_cast nehme ich, wenn ich einen wirklich häßlichen cast von nicht POD typen mache, ganz einfach weil ich dann schön danach suchen kann und den cast eliminiere sobald mir was besseres einfällt.



  • TheBigW schrieb:

    string myStr = "hallo"; //Konstruktoraufruf + op=
    string myStr("hallo"); //nur ctor
    

    Falsch - das erste ruft auch nur den Konstruktor auf. Die folgende Variante benötigt tatsächlich zwei Funktionen:

    string myStr;myStr="hallo";
    


  • TheBigW schrieb:

    sollte ich string eher so wie oben definieren, oder besser string = "hallo"?

    Ja

    string myStr = "hallo"; //Konstruktoraufruf + op=
    string myStr("hallo"); //nur ctor
    

    Das ist so nicht korrekt. Wenn überhaupt wird hier der Konvertierungs-Ctor und der Copy-Ctor aufgerufen, was der Compiler allerdings oftmals zu einem Ctor-Aufruf eliminiert. Der Zuweisungsoperator wird hier nicht aufgerufen. Siehe dazu auch: copyvsdirect.

    /edit: Zu spät...

    Gruß Caipi



  • volkard schrieb:

    wenn du anfängst, static_cast<string>("hallo") zu schreiben, überlege ich mir, ob ich static_cast<double>(int) schreibe.

    So mache ich das auch nicht. Aber nimm sowas wie von unsigned auf signed gehen(oder umgekehrt). Ich finde, da ist ein static_cast angebracht, weil es häßlich ist und damit auch häßlich aussehen sollte (imho). Kommt zum Beispiel gerne vor, wenn man ältere Libs mit STL benutzt...

    MfG Jester



  • string myStr;myStr="hallo";

    den Fall meinte ich auch - wieder was gelernt. Trotzdem finde ich in dem Fall string myStr("hallo") schöner.

    weil es häßlich ist und damit auch häßlich aussehen sollte

    👍 und man dann schön nach den häßlichen Stellen suchen kann. Wenn ich mal nachdenke gilt das eigentlich für fast alle der "neuen" casts. Ich versuche eigentlich, sobald ich sie mache, sie so schnell wie möglich wieder los zu werden.



  • Jester schrieb:

    Ich finde, da ist ein static_cast angebracht, weil es häßlich ist und damit auch häßlich aussehen sollte (imho).

    ok, dann herrsch ja konsens. nicht aus prinzip den einen oder anderen cast nehmen, sondern häßliche casts eher für häßliche dinge.



  • 3 schrieb:

    @rapso: dynamic_cast nicht.

    erstmal informieren..
    natürlich gibts nen
    dynamic_cast<T>();

    Mfg Shade37337



  • shade37337 schrieb:

    3 schrieb:

    @rapso: dynamic_cast nicht.

    erstmal informieren..
    natürlich gibts nen
    dynamic_cast<T>();

    Mfg Shade37337

    Ich glaube er meinte, dass der dynamic_cast nicht durch die C-Casts ersetzt werden kann:

    #include <iostream>
    
    struct frucht {
        virtual ~frucht() {}
    };
    
    class apfel : public frucht { };
    
    class birne : public frucht { };
    
    int main() {
        frucht* p = new apfel;
        std::cout << "C++ sagt:" << std::endl;
        if(dynamic_cast<apfel*>(p)) {
            std::cout << "Es ist ein Apfel!" << std::endl;
        }
        if(dynamic_cast<birne*>(p)) {
            std::cout << "Es ist eine Birne!" << std::endl;
        }
        std::cout << "\nC sagt:" << std::endl;
        if((apfel*)(p)) {
            std::cout << "Es ist ein Apfel!" << std::endl;
        }
        if((birne*)(p)) {
            std::cout << "Es ist eine Birne!" << std::endl;
        }
        delete p;
    }
    

    mfg.


Anmelden zum Antworten