Wann und wo die Endung "_t"?

Artchi

hustbaer schrieb:

Weglassen ist gut wenn man Typen und Variablen z.B. durch Case unterscheidet. Wenn man aber (wie im Standard) alles klein schreibt, kann das doof werden.

Beispiel:
struct functor
{
    struct context
    {
    };

    functor(context& context)
        : m_context(context)
    {
    }

    context& m_context;
};
Nicht sehr hübsch. (Weiss nichtmal ob das legal ist, ich schreib sowas nie.) In dem Fall ist es IMHO besser den Typ context einfach context_t zu nennen.

Wird nicht gehen... struct context ist definiert, das kann man nicht mehr als Variable benutzen.

DEvent

ten schrieb:

Apollon schrieb:

Wie waers mit einfach weglassen?

nö, das ist schlecht.
ich finde es ist schon eine wichtige information für leute, die ein programmm lesen, ob's ein selbstdefinierter typ ist oder nicht...

daran glaubst du doch nicht wirklich...?

Ceos

also bei mir haben alle von MIR definierten Typen ein großes T vorangestellt, so kann ich sogar von MIR definierte typen von standard typen unterscheiden ..... ... ... ..... ..... ich hab mich jetzt nicht wirklich hinreissen lassen den send button zu drücken oder ?

rüdiger

darthdespotism schrieb:

rapso schrieb:
neu im standard sind nun auch
int8_t
int16_t
int32_t
int64_t
uint8_t
uint16_t
uint32_t
uint64_t
was ich persoenlich sehr gut finde :), ich ueberlege ernsthaf von meinen sonstigen typedefs darauf umzusteigen
Was heißt neu im stan****? Seit wann?
Bei welchen Compilern funktioniert das? g++4?

Das ist aus dem C99-Standard (und wir auch hoffentlich im C++09 Standard aufgenommen!)

Boost hat dafür boost/cstdint.hpp. Ansonsten schau mal ob dein Compiler ein stdint.h hat.

<edit>Fehler behoben: stdint anstelle stddef</edit>

ten

Artchi schrieb:

ten schrieb:

Apollon schrieb:

Wie waers mit einfach weglassen?

nö, das ist schlecht.
ich finde es ist schon eine wichtige information für leute, die ein programmm lesen, ob's ein selbstdefinierter typ ist oder nicht...

Naja, nur in C++ sind ja alles selbt definierte Typen, außer die paar die wir sonst kennen. Jede Klasse in C++ ist ein selbstdefinierter Typ. Oder was verstehst du unter selbstdefinierter Typ?

da hast du natürlich recht.
ich hab's gar nicht aus der sicht eines c++ coders betrachtet.
hinter jede klasse ein _t zu schreiben sieht natürlich auch doof aus.
wenn ich c++'ler wäre, würde ich vielleicht nur hinter reine datenklassen das _t schreiben, und bei solchen, in denen die funktionalität steckt eben nicht...

DEvent schrieb:

ten schrieb:

Apollon schrieb:

Wie waers mit einfach weglassen?

nö, das ist schlecht.
ich finde es ist schon eine wichtige information für leute, die ein programmm lesen, ob's ein selbstdefinierter typ ist oder nicht...

daran glaubst du doch nicht wirklich...?

doch, guck' mal:

typedef struct blah {...} blah_t;
void f (blah_t *b);
blah_t g(void);
...
blah_t blah, anotherblah;
f (&blah);
anotherblah = g();
... // usw.

sieht man doch gleich dass 'blah_t' ein typ ist.
ich finde das _t macht den code etwas leserlicher als ohne...

rapso

Artchi schrieb:

...
Der Standard der noch in Arbeit ist, aber schon dieses Jahr der erste Entwurf raus kommt. Compiler gibts dafür noch nicht.

ich glaube das ist bei allen compilern mitlerweile dabei (mein cell-gcc kann das auf jeden fall, VC++ kann das glaube ich auch), man muss nur etwas dafuer includen, wenn es native unterstuetzung faende waere das super, ist ja nicht mehr lang hin, wobei boese zungen behaupten dass es sich bis C++0f hinziehen koennte mit dem C++0x-standard.

ich denke auch ein wenig, dass es garnicht gedacht ist diese typen direkt zu benutzen, sondern als stabile basis fuer die eigenen typedefs __int64, long long... das suckt einfach.

hustbaer

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

Artchi

Genau, meine den C++2009-Standard. Weil offiziell kennt C++ das C99 nicht. Deshalb ist es legitim das MSVC die ganzen oben genannten Typen nicht kennt, weil MSVC eher ein C++-Compiler und kein C-Compiler ist.
GCC ist dagegen eine Compiler Collection (aha!) und hat deshalb einmal einen C++-Compiler und C-Compiler der hoffentlich C99 kennt.

rapso

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.

ten

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.

.filmor

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

rüdiger

.filmor schrieb:

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

jo, war ein Fehler von mir.

Artchi

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.

Konrad Rudolph

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'?

Artchi

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

Konrad Rudolph

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.

CStoll

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.

Artchi

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

Bashar

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.

Artchi

Weil

if(nullptr == 0) // error,

auch nicht geht. Ist halt kein lvalue.

Wann und wo die Endung &quot;_t&quot;?

Wann und wo die Endung "_t"?