OK, also werde ich meine ganzen typedefs in meinen Projekten nicht mehr mit _t enden lassen?

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

Ob diese Konvention heute noch gebraucht wird weiß ich nicht, ich hoffe es jedenfalls nicht

Dafür nutzt man jetzt _type

template<...>
class basic_string {
// ...
public:
  typedef size_t size_type;
...
};

Bashar schrieb:

Ob diese Konvention heute noch gebraucht wird weiß ich nicht, ich hoffe es jedenfalls nicht

wieso findeste das doof?
was würdest du als ersatz vorschlagen?

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 Standart? Seit wann?
Bei welchen Compilern funktioniert das? g++4?

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...

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?

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

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.

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?

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.

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

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 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...

...
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.

@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.

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.

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

jo, war ein Fehler von mir.

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.