struct in Kombination mit typedef

[starcow]

Tach zusammen! :-)

Wenn ich ein struct im Zuge eines typedefs deklariere, dann habe ich ja im Wesentlichen "kombinatorisch" drei Möglichkeiten.

Code: Alles auswählen

typedef struct         { ... } name_t; // Das struct selbst ist anonym
typedef struct name_t  { ... } name_t; // Der struct "Identyfier" wird durch das typedef verdeckt
typedef struct name    { ... } name_t; // Es existieren zwei "Identyfier"

Wo liegen hier die Vorteile (Nachteile?) der verschiedenen Methoden?
In der WindowsAPI begegne ich durchgängig der dritten Methode.

Code: Alles auswählen

typedef struct tagNAME { ... } NAME, *PNAME;

Wie beurteilt ihr eigentlich die Konvention, dem per typedef definierten Typ das Postfix _t anzuhängen (Beispiel uint32_t)?
Sinnvolle Regel oder unnötiger Firlefanz? :-)

Gruss, starcow

[Alexander Kornrumpf]

Vielleicht solltest du dazu sagen, ob du versuchst C oder C++ zu schreiben, denn in C++ brauchst du das typedef gar nicht, soweit ich mich erinnere.

[Schrompf]

Ich kenne immer nur typedef _some_struct_t { ... } some_struct_t;, also Variante 3. Dass die gleich heißen dürfen, wusste ich nicht. Man macht das aber wirklich nur, weil man in C sonst immer struct SomeStruct obj; schreiben müsste, und das typedef erspart einem das struct vornedran. In C++ braucht es das nicht mehr, da typedeft beziehungsweise usingt man wirklich nur noch, wenn man ein Alias haben will.

[Krishty]

In meinem C-Code benutze ich gar nichts davon, sondern schreibe explizit struct Foo hin, wann immer ich es brauche. In C++ lohnt es zwar, den Typ einer Variable wegzuabstrahieren und nur die Semantik abzubilden (auto everywhere!), aber das geht eben nur in C++ – weil nur C++ erlaubt, eigene Typen zu schreiben, die sich wie ein int oder ein Zeiger oder sonstwas verhalten, unabhängig davon, ob sie nun als class oder enum class oder sonstwas implementiert sind.

In C geht das nicht. Du kannst in C keine Smart-Pointer-Klasse haben, weil ein struct immer komplett anders zu benutzen sein wird als ein int *. Es gibt ja keine überladenen Operatoren. COM & Co. versuchen das via Makro, aber dann sieht dein Code eh ganz anders aus.

Deshalb sehe ich nicht recht ein, das struct wegzu… aliasen? Das nennt man Alias, oder?

Anyway. Davon ab ist die Endung _t in POSIX reserviert. So lange du nur auf Windows kompilierst, kann dir das egal sein. Falls du mal auf Linux oder einem anderen POSIX-System kompilieren möchtest, ist das nicht mehr zukunftssicher, weil irgendwann ein Header einen eigenen Typ mit dem selben Namen einführen könnte. Nix Schlimmes, just saying.

[starcow]

Vielleicht solltest du dazu sagen, ob du versuchst C oder C++ zu schreiben, denn in C++ brauchst du das typedef gar nicht, soweit ich mich erinnere.

Stimmt, entschuldigt das Versäumnis! :-)
Ich dachte hier tatsächlich an plain C.

Dass die gleich heißen dürfen, wusste ich nicht.

Guter Punkt. Also ehrlich gesagt fehlt mir jetzt auch eine valide Referenz dafür, dass man das so machen darf. Weder clang noch gcc geben mir in diesem Zusammenhang eine Warnung aus - was ja aber eigentlich noch kein Garant dafür ist, dass dies auch tatsächlich erlaubt wäre. Hmmm...

In meinem C-Code benutze ich gar nichts davon, sondern schreibe explizit struct Foo hin, wann immer ich es brauche. In C++ lohnt es zwar, den Typ einer Variable wegzuabstrahieren und nur die Semantik abzubilden (auto everywhere!), aber das geht eben nur in C++ – weil nur C++ erlaubt, eigene Typen zu schreiben, die sich wie ein int oder ein Zeiger oder sonstwas verhalten, unabhängig davon, ob sie nun als class oder enum class oder sonstwas implementiert sind.
In C geht das nicht. Du kannst in C keine Smart-Pointer-Klasse haben, weil ein struct immer komplett anders zu benutzen sein wird als ein int *. Es gibt ja keine überladenen Operatoren. COM & Co. versuchen das via Makro, aber dann sieht dein Code eh ganz anders aus.

Deshalb sehe ich nicht recht ein, das struct wegzu… aliasen? Das nennt man Alias, oder?

Warte.
Ich dachte eigentlich genau das tut typedef. Damit etabliere ich doch einen neuen Typ? Hast du eine Situation im Kopf, die den Unterschied deutlich macht? So ganz kann ich dir noch nicht folgen.
Soweit ich sehe, wird typedef oft genutzt, einfach um weniger tippen zu müssen (struct fällt weg). Jedoch habe ich auch schon aufgeschnappt, dass das aus einem bestimmten Grund (der mir nicht klar ist) potentiell ungünstig sein kann.
Was sind deine Gründe, darauf zu verzichten?

Davon ab ist die Endung _t in POSIX reserviert. So lange du nur auf Windows kompilierst, kann dir das egal sein. Falls du mal auf Linux oder einem anderen POSIX-System kompilieren möchtest, ist das nicht mehr zukunftssicher, weil irgendwann ein Header einen eigenen Typ mit dem selben Namen einführen könnte. Nix Schlimmes, just saying.

Oh! Sehr guter Hinweis, danke!
kein _t anhängen, weil potentiell reserviert!

[dot]

Dass die gleich heißen dürfen, wusste ich nicht.

Guter Punkt. Also ehrlich gesagt fehlt mir jetzt auch eine valide Referenz dafür, dass man das so machen darf. Weder clang noch gcc geben mir in diesem Zusammenhang eine Warnung aus - was ja aber eigentlich noch kein Garant dafür ist, dass dies auch tatsächlich erlaubt wäre. Hmmm...

In C dürfen sie das. Grund ist, dass die Namen von structs und enums in C sogenannte Tags sind die effektiv einen eigenen separaten Namespace haben. typedef Names dagegen sind ordinary identifiers.

In meinem C-Code benutze ich gar nichts davon, sondern schreibe explizit struct Foo hin, wann immer ich es brauche. In C++ lohnt es zwar, den Typ einer Variable wegzuabstrahieren und nur die Semantik abzubilden (auto everywhere!), aber das geht eben nur in C++ – weil nur C++ erlaubt, eigene Typen zu schreiben, die sich wie ein int oder ein Zeiger oder sonstwas verhalten, unabhängig davon, ob sie nun als class oder enum class oder sonstwas implementiert sind.
In C geht das nicht. Du kannst in C keine Smart-Pointer-Klasse haben, weil ein struct immer komplett anders zu benutzen sein wird als ein int *. Es gibt ja keine überladenen Operatoren. COM & Co. versuchen das via Makro, aber dann sieht dein Code eh ganz anders aus.

Deshalb sehe ich nicht recht ein, das struct wegzu… aliasen? Das nennt man Alias, oder?

Warte.
Ich dachte eigentlich genau das tut typedef. Damit etabliere ich doch einen neuen Typ? Hast du eine Situation im Kopf, die den Unterschied deutlich macht? So ganz kann ich dir noch nicht folgen.
Soweit ich sehe, wird typedef oft genutzt, einfach um weniger tippen zu müssen (struct fällt weg). Jedoch habe ich auch schon aufgeschnappt, dass das aus einem bestimmten Grund (der mir nicht klar ist) potentiell ungünstig sein kann.
Was sind deine Gründe, darauf zu verzichten?

typedef macht keinen neuen Typ sondern führt einen Alias für einen bestehenden Typ ein:

Code: Alles auswählen

typedef int bla;

bla hier ist kein separater Typ, sondern nur ein Alias für den Typ int. In C merkt man den Unterschied kaum, in C++ merkt man ihn sofort:

Code: Alles auswählen

void fun(int) {}
void fun(bla) {}  // ERROR, fun already defined

[starcow]

Danke dot, sehr gut erklärt!

Könnte man nicht einfach dazu übergehen, ganz grundsätzlich anonyme structs in Kombination mit typedef zu verwenden (quasi als Standard)?

Code: Alles auswählen

typedef struct { ... } Name; // Das struct selbst ist anonym

Das ginge ja eigentlich einzig nur dann nicht, wenn ich innerhalb dieses structs noch einen Pointer des selben struct Typs benötige (z.B. bei einer Linked List).
Oder übersehe ich da vielleicht etwas?

[dot]

Könnte man nicht einfach dazu übergehen, ganz grundsätzlich anonyme structs in Kombination mit typedef zu verwenden (quasi als Standard)?

Naja, wie du selber schon angemerkt hast geht das halt nicht wenn dein struct Pointer auf sich selbst beinhalten soll. Abgesehen von einem solchen Fall kann man einfach typedef auf unnamed struct machen. Ist halt eine Frage der Konsistenz…