Ist dies eine gültige Typdefinition? Der Code kompiliert und läuft gut. Mich würde nur interessieren, ob das gängige Praxis ist.
alexkr
Absolut gültig. Normalerweise können Sie diese Methode voll ausnutzen, indem Sie zwei Typen zusammen definieren:
typedef struct
{
int a;
int b;
} S1, *S1PTR;
Wobei S1 eine Struktur ist und S1PTR der Zeiger auf diese Struktur ist.
…und vielleicht const *S1CPTR.
– alecov
17. Juni 2013 um 3:53 Uhr
Nur um zu bestätigen, dass ich es verstehe. Ist das gleichbedeutend mit typedef struct {...} S1; typedef S1* S1PTR;?
– DCShannon
12. Januar 2016 um 2:18 Uhr
Patrick Schlüter
Ja, so ist es. Aber es ist meiner Meinung nach schlechter Stil. Nicht die direkte Deklaration der Struktur, sondern die direkte Deklaration eines Zeigertyps. Es ist Verschleierung, die Information, dass eine bestimmte Variable oder ein Parameter ein Zeiger ist (und in geringerem Maße für Arrays), ist äußerst wichtig, wenn Sie Code lesen möchten.
Beim Review von Code ist oft auf den ersten Blick schwer zu erkennen, welche Funktion eine Nebenwirkung haben könnte oder nicht. Wenn die verwendeten Typen diese Informationen verbergen, fügt dies dem Leser eine Gedächtnislast hinzu.
int do_fancy(vector a, vector b);
oder
int do_fancy(vector *a, vector *b);
Im ersten Fall kann ich leicht übersehen, dass diese Funktion den Inhalt von a oder b ändern kann. Im zweiten bin ich gewarnt.
Und wenn ich eigentlich Code schreibe, weiß ich auch direkt zu schreiben a->x und lass es mir nicht vom Compiler sagen error: request for member x’ in etwas, das keine Struktur oder Vereinigung ist’.
Ich weiß, es scheint eine persönliche Geschmackssache zu sein, aber da ich mit viel externem Code gearbeitet habe, kann ich Ihnen versichern, dass es äußerst ärgerlich ist, wenn Sie die Indirektionsebene von Variablen nicht erkennen. Das ist ein Grund, warum ich auch C++-Referenzen (in Java nicht, weil alle Objekte als Referenz übergeben werden, es ist konsistent) und die von Microsoft nicht mag LPCSTR Art von Typen.
+1 für die Beobachtung, dass typedef struct { ... } *obj führt zu einem Typ, der auf mysteriöse Weise erfordert -> Anstatt von . für Elementzugriff.
– Michael
1. Oktober 2015 um 2:54 Uhr
Strenge Namenskonventionen würden den Benutzer über den Typedef-Typ informieren, also kein wirklich schlechter Stil. Ich sehe jedoch Ihren Standpunkt, wenn Sie mit externem Code arbeiten und verschiedene Codierungspraktiken verwenden.
– Neil
2. Juli 2018 um 15:06 Uhr
Ja, es ist gültig. Wenn Sie mehr “Sicherheit” brauchen, können Sie das auch tun
Aber vergessen Sie nicht das abschließende Semikolon.
Wenn Sie nur typedef verwenden, bedeutet dies, dass Sie es so benennen. sonst wäre es mehr oder weniger anonym.
Ich glaube, Sie können für beide denselben Namen verwenden (dh Sie brauchen den Unterstrich nicht, können aber alles andere in Ihrem Code gleich lassen, da die Namespaces getrennt sind).
– RastaJedi
14. September 2016 um 4:24 Uhr
Es ist ein gültiges, was es tut, es definiert einen neuen Typ. Wie @Alex sagte, wäre es nützlich, einen Typ und einen Zeigertyp zu definieren.
Sie könnten mehr Zeiger erstellen, indem Sie einfach verwenden
S1PTR ptr1, ptr2, ptr3, ...;
Anstatt von
S1 *ptr1, *ptr2, *ptr3, ...;
FIFO
Ja, es ist gültig, wie in den obigen Antworten beschrieben. Ein kleiner Vorschlag, es wäre besser, wenn Sie auch einen Tag-Namen wie folgt angeben. Dies würde einigen IDEs helfen, Ihren Code besser zu analysieren.