struct Foo und typedef struct Foo_

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.

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

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

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.

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.

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

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?

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.

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.

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.

es ist doch ein essentieller Unterscheid, ob ich von C oder von C++ rede, oder nicht? Das eine ist eine prozedurale Programmiersprache aus den 70er Jahren, mit der ich absolut Speicher und CPU effizient Coden kann - damals hat man auch die Notwenigkeit dafür noch gehbat. Zu Zeiten von C++ und C#, was nunmal der Objektorientierung angehört wird kaum mehr Wert auf Ressourceneffizienz gelegt. Man kann allerdings objektorientiert viel schneller kompelxe Programme stricken, ohne sich Gedanken machen zu müssen, wie kopmlexe Datentypen intern aussehen, wie sie behandelt werden müssen usw.! Die Anforderungen haben sich also im Laufe der von Ressourcenknappheit auf der hardwareseite nach Zeitknappheit bei der Entwicklung verlagert - und daraus resultiert nun mal eine vereinfachte Benutzung der Programmiersprache bei der gleichen Aufgabenstellung.

Und zu dem struct / enum oder typedef und nicht struct / enum: wenn man professionell programmiert und dabei auf eine gewisse Lesbarkeit und Wiederverwendbarkeit der eigenen Quelltexte achten muss kann man sicherlich auch die typedefs nicht allzu gut einsetzen, um dem "Wiederverwender" zu ermöglichen, den Quelltext sauber zu lesen ohne erst jedes Header-File studieren zu müssen. Wenn man allerdings privat codet und weiß, man wird nur selbst jemals den Quelltext zu Gesicht bekommen und man kann sich merken, wie man seine eigenen Datentypen, Strukturen, Enumerationen und so weiter definiert hat, dann kann man sie ja durchaus dem Compiler auch mit typedef bekannt geben.

Soviel zu meiner Meinung zu dem Thema - ob sie nun einer wissen will oder nicht!

@ Tim:

Das Problem dabei ist: FILE ist Well-Known und kann überall nachgeschaut werden. Wenn ich mir allerdings jetzt selbst eine Structur schreibe, die beispielsweise einen Mitarbeiter mit allen Attributen definiere sollte ich einem potenziellen Leser meines Codes schon die Möglichkeit geben, nach zu vollziehen, was ich tue und wie, oder meinst du nicht?