Warum kein "echter" 8 bit int?



  • Mal eine vielleicht naive Frage. Die Erkenntnis ist ja für alte C++ Hasen nicht neu, dass ein uint8_t nichts anderes als ein unsigned char mit all seinen Sonderbehandlungen ist und man sich da schwer auf die Schnauze legen kann, wenn man diese Sonderfälle vergisst zu berücksichtigen. Ich frage mich daher warum noch niemand auf die Idee gekommen ist, dem Standard einen "echten" Integer mit der Größe eines chars hinzuzufügen, der nicht nur ein Typedef ist. Im prinzip kann man sich ja so etwas schon fast als Klasse selber basteln wobei man trotz allem noch nicht alle Eigenschaften eines "eingebauten" Datentypes nachbilden kann.

    Ich frage mich auch wie das mit Concepts sein wird. char ist ja ein Typ der in vielen Aspekten wie ein int ist, in anderen aber nicht. Ob man das sauber auseinander halten kann?



  • TNA schrieb:

    char ist ja ein Typ der in vielen Aspekten wie ein int ist, in anderen aber nicht.

    char vielleicht, aber unsigned char oder signed char sind genau gleich wie int. Die Spezialfälle sind allesamt Fehldesign in der Standardbibliothek.

    Mir fehlen aber strong typedefs. Z.B. wenn ich irgendeine ID als int speichere. Dann mache ich

    using user_id = unsigned;
    

    , aber das schützt mich nicht vor Typfehlern. Ich will doch nicht ints nach user_ids konvertieren. Schön wäre etwas in der Art von

    using struct user_id = unsigned; // strong typedef
    

    wo user_id ein ganz neuer Typ ist, der die gleichen Eigenschaften wie unsigned besitzt.



  • stronger schrieb:

    char vielleicht, aber unsigned char oder signed char sind genau gleich wie int. Die Spezialfälle sind allesamt Fehldesign in der Standardbibliothek.

    Guter Einwand. So habe ich das noch nicht gesehen. Mir fällt aber auch kein Grund ein, warum ein unsigned char oder signed char die selben Sonderbehandlungen benötigen sollte wie char. Sind ja schließlich drei verschiedene Typen.

    stronger schrieb:

    Mir fehlen aber strong typedefs.

    So geht es mir auch. Mit C++11 kommt man ja schon recht nah an die Möglichkeit selbst definierten Typen die Eigenschaften von einem int zu geben, aber eben nur fast und nur mit viel Boilerplate-Code.



  • stronger schrieb:

    TNA schrieb:

    char ist ja ein Typ der in vielen Aspekten wie ein int ist, in anderen aber nicht.

    char vielleicht, aber unsigned char oder signed char sind genau gleich wie int. Die Spezialfälle sind allesamt Fehldesign in der Standardbibliothek.

    Erm.
    Diese Designfehler (wo ich dir zustimme dass es welche sind!) sind aber nunmal da. Und da die Spezialbehandlungen in der std. Library und Spezialregeln in der Sprache (z.B. was strong aliasing angeht) das einzige sind was char, unsigned char und signed char besonders macht, macht die Behauptung "char vielleicht, aber unsigned char oder signed char sind genau gleich wie int" mMn. keinen Sinn. Es sollte vielleicht so sein, aber es ist eben nicht so.

    stronger schrieb:

    Mir fehlen aber strong typedefs. (...) Schön wäre etwas in der Art von

    using struct user_id = unsigned; // strong typedef
    

    wo user_id ein ganz neuer Typ ist, der die gleichen Eigenschaften wie unsigned besitzt.

    Ja, das wäre praktisch! Weiss nicht ob mir die Syntax gefällt, aber die Funktionalität wäre praktisch.



  • Ist wohl ein Relikt aus 16-Bit-Zeiten.
    Zeiten als XOR AL, AH noch gängige Praxis waren.

    EDIT:
    Oder XOR AL, AL - weil ich ja schließlich einen cycle schneller damit bin.



  • Mit C++11 kommt man ja schon recht nah an die Möglichkeit selbst definierten Typen die Eigenschaften von einem int zu geben, aber eben nur fast und nur mit viel Boilerplate-Code.

    Da würde mich jetzt ein (rudimentäres) Beispiel interessieren, wie kann ich mir das vorstellen?



  • Mich würde dabei hauptsächlich interessieren warum man dazu C++11 braucht...
    Wegen der "relaxed POD Regeln"? Enum class? ...?



  • hustbaer schrieb:

    Mich würde dabei hauptsächlich interessieren warum man dazu C++11 braucht...
    Wegen der "relaxed POD Regeln"? Enum class? ...?

    Ich dachte in erster Linie an constexpr. Bisher komme ein selbstdefinierter Typ nie eine compilezeit-Konstanten sein. Ob das jetzt bei einem ID so wichtig ist sei mal dahingestellt. Für Flag Klassen ist das aber essentiell. Auch durch User-defined literals kann man etwas machen, was sonst nur eingebaute Typen können wobei das nur syntaktic sugar ist.



  • *self-facepalm*

    Natürlich 🙂
    Danke.


Log in to reply