struct Foo und typedef struct Foo_

[enumerator-freak]

DEvent schrieb:

Bei einem enum muss ich doch auch nicht immer enum hinschreiben.

doch, musste genau so tun.

enum my_enum
{
 a, b, c
};
...
enum my_enum e1 = a;  // geht
my_enum e2 = a;       // geht nicht

ein typ wird erst mit 'typedef' daraus.

[DEvent]

@enumerator-freak oh ok, hab ich uebersehen.

Aber die Entwickler von C muessen sich doch was dabei gedacht haben? Macht es den Compiler einfacher?

Definieren echte C programmierer einen struct mit oder ohne typedef?

[waschechter c coder]

DEvent schrieb:

Definieren echte C programmierer einen struct mit oder ohne typedef?

weder noch, die machen alles mit bitshifts und xors und macros

[supertux]

DEvent schrieb:

Hallo
wieso muss man eigentlich in C wenn man einen struct definiert, das Schluesselwort struct immer dazu schreiben? Welchen tieferen Sinn hat den das?

so ist nun mal die C Grammatik definiert

typedef ist da, um sich einen Datentyp zu erstellen, deswegen brauchst du das 'struct' danach nicht mehr, weil der Compiler dann weiß, dass es sich dabei um einen "struct {}" handelt.

Definieren echte C programmierer einen struct mit oder ohne typedef?

Ich benutze typedef ganz selten. Manchmal ist es nett, wenn man sich Tipparbeit erspart, aber gerade bei structs sehe ich keinen Gewinn dadurch. typedef benutze ich aber, wenn ich mit Funktionspointern arbeite, da ist ein typedef schon sehr sinnvoll.

[typedef-freak]

DEvent schrieb:

Definieren echte C programmierer einen struct mit oder ohne typedef?

das ist sehr unterschiedlich. ich 'typedeffe' fast jede struct. andere verwenden fast nie typedef. kommt drauf an, was man lieber mag.

[feigling]

Swordfish schrieb:

feigling schrieb:

Weils einfach so ist. Was für ne komische Frage .. Du könntest genauso fragen, warum der Kopf der for-Schleife genauso aufgebaut ist wie er ist und nicht anders.

Tolle Antwort

Die Frage ist schon berechtigt. Hab' ich eine Struct

struct tag_foo_t {

    int bar;
};

// kann ich durch ein

typedef struct tag_foo_t foo_t;

// vermeiden, immer "struct" vor die Deklarationen von Instanzen der Struktur schreiben zu müssen:

foo_t my_foo;

greetz, Swordfish

Deine ist aber auch nicht besser. Oder ich habe die Frage missverstanden. Ich habe unter der Frage verstanden, warum man bei nem struct immer "struct" vorschreiben muss, außer man hat ein typedef. Und die Antwort ist halt .. weils so vorgeschrieben ist O_o Die Frage war nicht, was der Unterschied zwischen den beiden Varianten ist ..

[T2.0]

feigling hat vollkommen Recht. Der "tiefere Sinn", den du suchst, heißt Konvention.

[Gast]

T2.0 schrieb:

feigling hat vollkommen Recht. Der "tiefere Sinn", den du suchst, heißt Konvention.

Konvention ist der falsche Begriff. Es ist eine (harte) Regel die der ANSI/ISO-Standard aufstellt. Eine Konvention wäre z.B. dass getypedefte Typen das Anhängsel _t bekommen.

[T2.0]

Haar in der Suppe?

[DEvent]

Sind wir im Religionsunterricht?
"Weil es halt so ist, weil es halt so in der Bibel (der C-ISO-Standard) steht"

Wieso wurde das so in den C-ISO-Standard aufgenommen? Hat man eine Muenze geworfen, Kopf ist das man "struct" vor dem Struct hinschreiben muss, bei Zahl nicht?

typedef ist da, um sich einen Datentyp zu erstellen, deswegen brauchst du das 'struct' danach nicht mehr, weil der Compiler dann weiß, dass es sich dabei um einen "struct {}" handelt.

Also der Compiler weis nicht das Foo ein struct ist, obwohl ich ihn als struct Foo {}; definiert habe?

[LordJaxom]

DEvent schrieb:

Wieso wurde das so in den C-ISO-Standard aufgenommen? Hat man eine Muenze geworfen, Kopf ist das man "struct" vor dem Struct hinschreiben muss, bei Zahl nicht?

Philosophisch wäre genauso die Frage "wieso hätten sie es nicht so aufnehmen sollen". Daher bringt es absolut nichts sich darüber den Kopf zu zerbrechen. Vermutung meinerseits: Man hat einfach nicht die Möglichkeit bedacht, oder hat absichtlich nicht gewollt, dass ein Struct-Name gleichzeitig ein Typ-Name wird.

[Gast]

"struct" ist in C kein Typ. "struct name" aber schon (int == int, struct != struct).

[weglass-freak]

LordJaxom schrieb:

Man hat einfach nicht die Möglichkeit bedacht, oder hat absichtlich nicht gewollt, dass ein Struct-Name gleichzeitig ein Typ-Name wird.

warum sollte man bei 'struct' eine ausnahme machen, wenn's z.b. bei 'enum' und 'union' anders wäre? das fände ich ziemlich inkonsistent und schliesslich, wer schreibfaul ist, der kann ja zu 'typedef' greifen.
anderseits würde es bestimmt funktionieren, wenn man struct/enum/union weglassen würde. ich kann mir keinen nachteil vorstellen, aber die iso/ansi-verfasser sind bestimmt schlauer als ich, denn sonst hätten sie's bestimmt anders gemacht.

[Bashar]

DEvent schrieb:

Wieso wurde das so in den C-ISO-Standard aufgenommen? Hat man eine Muenze geworfen, Kopf ist das man "struct" vor dem Struct hinschreiben muss, bei Zahl nicht?

Der ISO-Standard ist von 1990, C ist in den 70ern entwickelt worden. Es dürfte einleuchten, dass man dort größtenteils keine neuen Entscheidungen getroffen hat, sondern existierende Implementationen als Grundlage genommen hat.

[LordJaxom]

anderseits würde es bestimmt funktionieren, wenn man struct/enum/union weglassen würde. ich kann mir keinen nachteil vorstellen, aber die iso/ansi-verfasser sind bestimmt schlauer als ich, denn sonst hätten sie's bestimmt anders gemacht.

Vielleicht ist zu der Zeit als C entwickelt wurde auch einfach niemand auf die Idee gekommen, ein Struct-Tag auch gleich als Symbol in die Symboltabelle aufzunehmen, weil es nicht notwendig schien. In C++ wollte man vielleicht das Verhalten integraler Typen für Klassen (Operatorenüberladung etc.) imitieren.

Aber das ist und bleibt Spekulation, solange nicht jemand nen Interview mit den Mitgliedern des 1989er-ANSI-Komitees arrangiert

[pointercrash**]

weglass-freak schrieb:

anderseits würde es bestimmt funktionieren, wenn man struct/enum/union weglassen würde.

Oh, struct und union brauche ich wirklich, die Alternativen wären wirklich BASIC- mäßig zerfledderte Konstruktionen.
Wenn ich ehrlich bin, habe ich außer zu akademischen Zwecken (mal probiert halt) noch nie typedef oder enum eingesetzt, die waren wirklich verzichtbar. Enumerationen bilde ich per define ab, structs und Funktionspointer schreibe ich lieber aus, damit mir auch später klar ist: Hoppla, denk' nach, was Du da tust.

Asche über mein Haupt, wenn ich da dem C- Puristen auf die Zehen latsche, aber da ich nie aufhören möchte, zu lernen: Inwiefern sollen typedef und enum unverzichtbar sein?

[typedef-freak]

pointercrash() schrieb:

Enumerationen bilde ich per define ab,

geht ja auch, aber ich finde bei enums das automatische hochzählen praktisch und dass der compiler meckert, wenn man hardcodierte werte doppelt hat. bei #defines haste ja diese compilerunterstützung nicht.

pointercrash() schrieb:

structs und Funktionspointer schreibe ich lieber aus...

naja, es gibt schon echt fiese konstruktionen, die ohne 'typedef' super-hässlich und unleserlich sind.

pointercrash() schrieb:

Inwiefern sollen typedef und enum unverzichtbar sein?

das sagt ja keiner. ich meinte das

enum lala
{
  A,B,C
};

union puh
{
 int a;
 char c;
};
...
enum lala l;
union puh p;
...

also beim anlegen von instanzen muss man 'enum' und 'union' hinschreiben, sonst frisst's der compiler nicht. normalerweise aber könnte es auch ohne gehen. ich wüsste jedenfalls keinen nachteil, ausser einer vielleicht schlechteren lesbarkeit. aber die hat man ja auch, wenn man's 'typedef'd' und miese typnamen wählt.

[DEvent]

naja, es gibt schon echt fiese konstruktionen, die ohne 'typedef' super-hässlich und unleserlich sind.

In C gehts ja noch, aber in C++ wirds wegen Templates schon unuebersichtlich.

[typedeffer-freak]

DEvent schrieb:

naja, es gibt schon echt fiese konstruktionen, die ohne 'typedef' super-hässlich und unleserlich sind.

In C gehts ja noch, aber in C++ wirds wegen Templates schon unuebersichtlich.

mag sein, aber auf c++ kann man zum glück so gut wie immer verzichten.

[Gast]

pointercrash() schrieb:

Inwiefern sollen typedef und enum unverzichtbar sein?

Unverzichtbar sicher nicht. Aber ein typedef ist u.a. sehr geschickt weil man manchmal halt eben die Implementierung hinter dem Typ verstecken will. Beispiel FILE . Man braucht überhaupt nicht zu wissen was sich dahinter verbirgt, struct, union, bitfield, int. Alles läuft über die gegebenen Schnittstellen (fopen, fclose, fwrite, ...) ab.