Typangabe bei Casts



  • Hallo

    Wenn ich einen int mit static_cast in einen char und dann implizit in einen bool konvertieren will schreibe ich:

    int foo = 1;
    bool bar = static_cast<char>(foo);
    

    Hier ist die explizite Typangabe sinnvoll. Wozu will das Sprachmittel bei folgendem Code den Typ explizit von mir wissen (es ist ein Sprachmittel, es kann den gewünschten Zieltyp sicher ermitteln)?

    int foo = 1;
    char bar = static_cast<char>(foo);
    

    Wäre es nicht weitaus sinnvoller, dass es selbst schaut wo das Resultat genutzt wird und dann eben den Typ davon verwendet?

    MfG, EOutOfResources



  • Im zweiten Fall ist der Cast imho unnötig, da reicht auch eine implizite Typumwandlung. Und selbst das erste Beispiel sieht unsinnig aus.

    Ansonsten: Der Compiler betrachtet den Cast für sich alleine, bevor er sich überlegt, was er mit dem Ergebnis machen soll - das könnte ja auch etwas viel komplizierteres sein als eine einfache Zuweisung 😉



  • CStoll schrieb:

    Im zweiten Fall ist der Cast imho unnötig, da reicht auch eine implizite Typumwandlung. Und selbst das erste Beispiel sieht unsinnig aus.

    Natürlich. Es sind ja Beispiele.

    CStoll schrieb:

    das könnte ja auch etwas viel komplizierteres sein als eine einfache Zuweisung 😉

    Mir fällt auf die schnelle keinen Bereich ein, wo der Typ nicht ermittelbar sein sollte. Bei Überladung gibt es halt eben einen Fehler wegen Mehrdeutigkeit.



  • CStoll schrieb:

    Im zweiten Fall ist der Cast imho unnötig, da reicht auch eine implizite Typumwandlung. Und selbst das erste Beispiel sieht unsinnig aus.

    Ansonsten: Der Compiler betrachtet den Cast für sich alleine, bevor er sich überlegt, was er mit dem Ergebnis machen soll - das könnte ja auch etwas viel komplizierteres sein als eine einfache Zuweisung 😉

    Außerdem ist ein Cast ja, obwohl er ein Schlüsselwort ist, eigentlich eine Template-Funktion und bei der kann man Rückgabetypen nicht überladen - alles andere wäre verwirrend, inkonsistent und würde möglicherweise zu Uneindeutigkeiten führen (wie oben erwähnt).

    EDIT: Wenn schon keine Möglichkeit der impliziten Umwandlung besteht und du bspw. einen automatischen reinterpret_cast<>() verwenden willst, solltest du dir bewusst sein, dass ein Cast auch dazu da ist, dass du auf dein Programmdesign aufmerksam wirst.



  • EOutOfResources schrieb:

    Mir fällt auf die schnelle keinen Bereich ein, wo der Typ nicht ermittelbar sein sollte. Bei Überladung gibt es halt eben einen Fehler wegen Mehrdeutigkeit.

    Bei Überladungen bekommst du mitunter keinen Fehler, weil eine der Funktionen exakt passt - nur nicht die, die du eigentlich benötigen würdest. Und bei Templates mußt du mitunter sicherstellen, daß alle Parameter den selben Typ haben.



  • EOutOfResources schrieb:

    Mir fällt auf die schnelle keinen Bereich ein, wo der Typ nicht ermittelbar sein sollte. Bei Überladung gibt es halt eben einen Fehler wegen Mehrdeutigkeit.

    weist du was du da sagst?

    klar, alles ermittelbar für den compiler, aber hast du dir auch mal gedanken gemacht warum das nicht gemacht wird?

    sagen dir formale sprachen und in dem zusammenhang grammatiken, chomsky hierarchie, automaten theorie und regulär bzw. kontextfrei etwas?

    regularität ist was cooles, vor allem ist es schnell.
    kontextfreiheit ist auch gut und recht leistungsfähig, es ist zwar langsamer als reguläre sprachen aber noch schnell genug

    und was du da möchtest ist kontextsensitivität... (C++ ist eh schon nicht mehr kontextfrei)
    und das ist langsam, trotz der rekusionstiefe beim backtracking von 1 !

    würde der compiler überall noch gucken wofür ein ausdruck verwandt würde, dann wärst du mit einem hallo welt programm auf einem supercomputer 3 stunden am kompilieren - viel spass !



  • Skym0sh0 schrieb:

    weist du was du da sagst?

    klar, alles ermittelbar für den compiler, aber hast du dir auch mal gedanken gemacht warum das nicht gemacht wird?

    Versteh ich grad falsch, oder behauptest du, es gäbe keine Typinferenz?


Anmelden zum Antworten