3. Wann und wo die Endung "_t"?

Wann und wo die Endung "_t"?

  • R

    hustbaer schrieb:

    @rapso:
    Ich denke er meinte den *ganzen* neuen Standard, nicht bloss die int32_t Geschichte (die MSVC im Übrigen nicht kennt).

    gibt es einen noch neueren als C++0x von dem ich sprach?

    und stimmt, man muss sich die noetigen header(inttypes.h) runterladen.

    0
  • T

    Artchi schrieb:

    Deshalb ist es legitim das MSVC die ganzen oben genannten Typen nicht kennt, weil MSVC eher ein C++-Compiler und kein C-Compiler ist.

    diese _t typen stecken in der 'stdint.h'.
    ich schätze man muss die nur bei msvc includen, dann hat man die.
    kann mir nicht vorstellen, dass ms das einfach vergessen hat.

    0
  • .

    Übrigens sind die in Boost auch in cstdint.hpp, nicht cstddef.hpp afaik.

    0
  • R

    .filmor schrieb:

    Übrigens sind die in Boost auch in cstdint.hpp, nicht cstddef.hpp afaik.

    jo, war ein Fehler von mir.

    0
  • A

    Muß den nochmal rauskramen...

    Habe was gefunden, im null-Pointer Proposal:

    We also provide the typedef: typedef decltype(nullptr) nullptr_t;
    nullptr_t is not a reserved word. It is a typedef (as its _t typedef indicates) ...

    Quelle: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2214.pdf

    Wenn ich das richtig interpretiere: typedefs die aus einem build-in Typ entstehen, sollte man mit einem _t enden lassen.

    0
  • K

    Artchi schrieb:

    Muß den nochmal rauskramen...

    Habe was gefunden, im null-Pointer Proposal:

    We also provide the typedef: typedef decltype(nullptr) nullptr_t;
    nullptr_t is not a reserved word. It is a typedef (as its _t typedef indicates) ...

    Quelle: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2214.pdf

    Wenn ich das richtig interpretiere: typedefs die aus einem build-in Typ entstehen, sollte man mit einem _t enden lassen.

    Was mich in diesem Zusammenhang interessieren würde: Was ist denn dann 'nullptr_t'? 'void*'? Oder 'int'? Oder 'ptrdiff_t'?

    0
  • A

    Weiß nicht was du genau fragen willst. nullptr_t ist nur ein Typedef auf nullptr, und wird laut Proposal auch kaum genutzt werden. Frage sollte dann eher lauten, was nullptr ist. Und das ist, was es heißt. (sagt das Proposal wörtlich!) Es ist ein Nullpointer. Deshaln wird sowas nicht gehen:

    if( nullptr) // error
{}
nullptr + 2; // error!
int n = nullptr; // error!
char *ch = nullptr; // ok
    0
  • K

    Artchi schrieb:

    Weiß nicht was du genau fragen willst. nullptr_t ist nur ein Typedef auf nullptr

    Eben. Und was ist denn nun der Typ von 'nullptr'? Ich hätte jetzt ehrlich gesagt gedacht, dass 'nullptr' keinen Typ hat, so wie 'null' in anderen Sprachen ebenfalls keinen wohldefinierten Typ hat. Dass man allerdings für den Typ von 'nullptr' ein Typedef ableiten kann, scheint für mich zu suggerieren, dass der Tp von 'nullptr' wohldefiniert ist.

    0
  • C

    Konrad Rudolph schrieb:

    Artchi schrieb:

    Weiß nicht was du genau fragen willst. nullptr_t ist nur ein Typedef auf nullptr

    Eben. Und was ist denn nun der Typ von 'nullptr'?

    Das steht doch auch in dem Proposal - ein implementations-spezifischer Typ, der nur in beliebige Pointer-Typen (und Member-Pointer) umgewandelt werden kann.

    0
  • A

    Die Implementierung von nullptr ist denke ich mal nicht vorgegeben. Denn es ist eigentlich auch unwichtig, da es ja nur zur Compiletime wichtig ist, das es nullptr gibt. Es soll ja den Kontext für den Compiler klarer machen. Zur Laufzeit wird es wahrscheinlich weiterhin ein sizeof(void*) sein. Wie es der Compiler-Hersteller will...

    Das typedef sieht ja konkret so aus:

    typedef decltype(nullptr) nullptr_t;

    Und wenn ich decltype richtig verstanden habe, soll es den Typ rausfinden. Also typedef nullptr nullptr_t; würde wahrscheinlich nicht funktionieren.

    Aber mit decltype kenne ich mich noch nicht so gut aus, vielleicht wird ja jemand anderes schlauer draus:
    http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1978.pdf

    0
  • B

    Artchi schrieb:

    if( nullptr) // error

    Wieso das denn? Damit tun sie sich glaub ich keinen Gefallen ...

    @Konrad Rudolph: Auch wenn der "null type" in der Sprache selbst nicht ausgedrückt werden kann, ist er doch trotzdem wohldefiniert.

    0
  • A

    Weil

    if(nullptr == 0) // error,

    auch nicht geht. Ist halt kein lvalue.

    0
  • B

    if (0) geht aber und 0 ist auch kein lvalue. Was soll lvalue oder nicht lvalue überhaupt damit zu tun haben?

    0
  • K

    Artchi schrieb:

    typedef decltype(nullptr) nullptr_t;

    Und wenn ich decltype richtig verstanden habe, soll es den Typ rausfinden.

    Ja, natürlich. Das Proposal für 'decltype' ist eigentlich recht klar, sozusagen als Komplement zu 'auto' (also nicht die Speicherklasse sondern als Compiletime-Duck-Typing):

    auto x = 1;        // decltype(x) == int, dasselbe wie:
decltype(1) y = 1;

    Also typedef nullptr nullptr_t; würde wahrscheinlich nicht funktionieren.

    Nö, natürlich nicht. 🙂 'nullptr' ist ja kein Typ.

    Bashar schrieb:

    @Konrad Rudolph: Auch wenn der "null type" in der Sprache selbst nicht ausgedrückt werden kann, ist er doch trotzdem wohldefiniert.

    Hmm, was ich meinte, ist, dass 'null' in einigen anderen Sprachen typenlos ist, es sei denn, man weist es einer typisierten Variable zu oder castet es explizit in einen Typ.

    0
Anmelden zum Antworten