Welchen Sinn hat "typedef struct"

[Dirk F. (dirkf)]

Hallo,
aus einem Beispielcode wird folgender code verwendet:

---------------------------------
typedef struct
{
    CLK_STATES clkstate;   // the current state
    int idlecnt;   // counts the number of times in the CLKS_STATE_IDLE
    unsigned int cpucycles;  // records the CPU cycles every second
    unsigned int last_CP0;  // the last core timer count
    int idlecntpersec;      // the idle count at the end of every second
} CLKDATA;
------------------------------------
CLKDATA clkData;
-----------------------------------
void CLKS_Initialize ( void )
{    
    clkData.cpucycles = 0;
    clkData.last_CP0 = 0;
    clkData.idlecnt = 0;
    clkData.idlecntpersec = 0;
    clkData.clkstate = CLKS_STATE_INIT;     
}
-------------------------------------

Frage: Welchen Vorteil bietet so etwas ?
Warum nicht einfach normale Varriablennamen verwenden ?
z.B.:
cpucycles = 0;
last_CP0 = 0;

[Mod: C-Code nachträglich formatiert]

[Harald K. (kirnbichler)]

Eine Struktur dient dazu, mehrere funktional zusammengehörende Variablen 
zusammenzufassen.

Das ist schon dann sinnvoll, wenn man diese Variablen einer Funktion 
übergeben möchte:

typedef struct
{
    CLK_STATES clkstate;
    int idlecnt;
    unsigned int cpucycles; 
    unsigned int last_CP0; 
    int idlecntpersec;  
} CLKDATA;

// a: 

void meine_funktion_a(CLK_STATES clkstate, int idlecnt, unsigned int cpucycles, unsigned int last_CP0, int idlecntpersec);

// b:

void meine_funktion_b(CLKDATA clkdata);

Du siehst, daß die Parameterliste von meine_funktion_a unanständig lang 
wird.


Das ganze geht übrigend auch ohne typedef:

struct CLKDATA
{
    CLK_STATES clkstate;
    int idlecnt;
    unsigned int cpucycles; 
    unsigned int last_CP0; 
    int idlecntpersec;  
};

// a: 

void meine_funktion_a(CLK_STATES clkstate, int idlecnt, unsigned int cpucycles, unsigned int last_CP0, int idlecntpersec);

// b:

void meine_funktion_b(struct CLKDATA clkdata);

Durch das typedef spart man sich das Hinschreiben des Schlüsselworts 
"struct" und man kann die Typdefinition syntaktisch genauso verwenden, 
wie einen anderen Datentyp.


Du plenkst.

[(prx) A. K. (prx)]

Dirk F. schrieb:
> Welchen Vorteil bietet so etwas ?

Stell dir vor, die Kiste hätte 2 CPUs:
CLKDATA clkData[2];

[Markus F. (mfro)]

typedef struct { 
...
} struct_typ;
struct_typ s;
s x;

Ist die Verbandelung einer Strukturdeklaration mit einem typedef und hat 
erst mal keinen Vorteil (ausser dass man sich u.U. ein wenig Tipparbeit 
spart, wenn man diesen Typ oft benutzt), weil man genauso gut auch

struct s
{
...
};
struct s x;

schreiben kann. Ich persönlich sehe keinen wirklich sinnvollen Grund, 
warum man für jede struct ein "typedef" erfinden müsste.

[Harald K. (kirnbichler)]

Markus F. schrieb:
> Ich persönlich sehe keinen wirklich sinnvollen Grund,
> warum man für jede struct ein "typedef" erfinden müsste.

Man spart sich das Schlüsselwort "struct" beim Gebrauch, und syntaktisch 
sieht das ganze so aus wie jeder beliebige andere Typ. Das ist also im 
wesentlichen eine Kombination aus Bequemlichkeit und Kosmetik.

[Cyblord -. (cyblord)]

Dirk F. schrieb:
> Frage: Welchen Vorteil bietet so etwas ?

Stell dir vor du hast 2 Sätze solcher Variablen. Oder du willst eine 
solche Struktur an eine Funktion übergeben (bzw. ein Pointer darauf).

[Markus F. (mfro)]

Harald K. schrieb:
> syntaktisch
> sieht das ganze so aus wie jeder beliebige andere Typ

Genau. Und warum sollte das so aussehen? Ich finde es gut, wenn man 
einer Struktur sofort ansieht, dass sie eine Struktur ist. Genauso mache 
ich das auch mit unions und enums.

Aber das ist zum grossen Teil natürlich Geschmackssache.

[Dirk F. (dirkf)]

OK  Danke euch.
Also ich brauchs in meinem Fall nicht....

[Benedikt M. (bmuessig)]

Die Verwendung eines Structs eröffnet darüber hinaus einen neuen 
Namensraum für die enthaltenen Felder.

So werden die Felder, die zu CLKDATA gehören sauber abgekapselt und 
überschneiden sich global nicht namentlich.

struct CLKDATA
{
    CLK_STATES clkstate;
    int idlecnt;
    unsigned int cpucycles;
    unsigned int last_CP0;
    int idlecntpersec;
};

uint8_t clkstate;

[Xanthippos (xanthippos)]

> Also ich brauchs in meinem Fall nicht....

Du wirst es erst brauchen, wenn du mit einem dutzend Kollegen größere 
Programme entwickelst. Bei 100 Quelltexten, willst du nicht mehr die 
100000 einzelnen Variablen kennen. Das wird viel zu aufwendig.

Der eine Kollege schreibt das CLKS_Initialize(), der andere den 
Hardware-Abstraction-Layer. Und du willst das einfach nur benutzen, 
willst dich nicht mehr um die 1000 internen Details kümmern.

[Dirk F. (dirkf)]

Ja stimmt.

[Oliver S. (oliverso)]

Xanthippos schrieb:
>> Also ich brauchs in meinem Fall nicht....
>
> Du wirst es erst brauchen, wenn du mit einem dutzend Kollegen größere
> Programme entwickelst

Oder auch andere, oder überhaupt welche, bei denen man das einfach sehr 
sinnvoll nutzen kann.

Auf einem kleinen Mikrocontroller mag es auch ohne gehen, im richtigen 
Leben nicht.

Oliver