Ho visto molti programmi costituiti da strutture come quella qui sotto

typedef struct 
{
    int i;
    char k;
} elem;

elem user;

Perché è necessario così spesso? Qualche motivo specifico o area applicabile?

Come ha detto Greg Hewgill, il typedef significa che non devi più scrivere ovunque struct. Ciò non solo consente di risparmiare la pressione dei tasti, ma può anche rendere il codice più pulito poiché fornisce una smidgen più astrazione.

Cose come

typedef struct {
  int x, y;
} Point;

Point point_new(int x, int y)
{
  Point a;
  a.x = x;
  a.y = y;
  return a;
}

diventa più pulito quando non è necessario vedere la parola chiave "struct" in tutto il luogo, sembra più che ci sia davvero un tipo chiamato "Point" nella tua lingua. Il che, dopo il typedef, è il caso immagino.

Nota anche che mentre il tuo esempio (e il mio) ha omesso di nominare struct se stesso, in realtà è utile anche quando vuoi fornire un tipo opaco. Quindi avresti il ​​codice come questo nell'intestazione, ad esempio:

typedef struct Point Point;

Point * point_new(int x, int y);

e quindi fornire la structdefinizione nel file di implementazione:

struct Point
{
  int x, y;
};

Point * point_new(int x, int y)
{
  Point *p;
  if((p = malloc(sizeof *p)) != NULL)
  {
    p->x = x;
    p->y = y;
  }
  return p;
}

In quest'ultimo caso, non è possibile restituire il punto in base al valore, poiché la sua definizione è nascosta agli utenti del file di intestazione. Questa è una tecnica ampiamente utilizzata in GTK + , ad esempio.

AGGIORNAMENTO Si noti che ci sono anche progetti C molto apprezzati in cui questo uso di typedefnascondere structè considerato una cattiva idea, il kernel Linux è probabilmente il progetto più noto. Vedi il capitolo 5 del documento Linux Kernel CodingStyle per le parole arrabbiate di Linus. :) Il mio punto è che il "dovrebbe" nella domanda forse non è incastonato nella pietra, dopo tutto.

È incredibile quante persone sbagliano. PER FAVORE non digitare le strutture in C, inquina inutilmente lo spazio dei nomi globale, che in genere è molto inquinato già nei grandi programmi C.

Inoltre, le strutture typedef'd senza un nome tag sono la causa principale dell'imposizione inutile delle relazioni di ordinamento tra i file di intestazione.

Prendere in considerazione:

#ifndef FOO_H
#define FOO_H 1

#define FOO_DEF (0xDEADBABE)

struct bar; /* forward declaration, defined in bar.h*/

struct foo {
  struct bar *bar;
};

#endif

Con una tale definizione, non usando typedefs, è possibile che un'unità compiland includa foo.h per arrivare alla FOO_DEFdefinizione. Se non tenta di dereferenziare il membro 'bar' della foostruttura, non sarà necessario includere il file "bar.h".

Inoltre, poiché gli spazi dei nomi sono diversi tra i nomi dei tag e i nomi dei membri, è possibile scrivere codice molto leggibile come:

struct foo *foo;

printf("foo->bar = %p", foo->bar);

Poiché gli spazi dei nomi sono separati, non vi sono conflitti nelle variabili di denominazione coincidenti con il nome del tag struct.

Se devo mantenere il tuo codice, rimuoverò le tue strutture dattiloscritte.

Da un vecchio articolo di Dan Saks ( http://www.ddj.com/cpp/184403396?pgno=3 ):

Le regole del linguaggio C per la denominazione delle strutture sono un po 'eccentriche, ma sono piuttosto innocue. Tuttavia, quando estese alle classi in C ++, quelle stesse regole aprono piccole crepe per la scansione dei bug.

In C, il nome appare in

struct s
    {
    ...
    };

è un tag. Il nome di un tag non è un nome di tipo. Data la definizione sopra, dichiarazioni come

s x;    /* error in C */
s *p;   /* error in C */

sono errori in C. È necessario scriverli come

struct s x;     /* OK */
struct s *p;    /* OK */

I nomi dei sindacati e delle enumerazioni sono anche tag anziché tipi.

In C, i tag sono distinti da tutti gli altri nomi (per funzioni, tipi, variabili e costanti di enumerazione). I compilatori C mantengono i tag in una tabella dei simboli concettualmente se non fisicamente separata dalla tabella che contiene tutti gli altri nomi. Pertanto, è possibile che un programma C abbia sia un tag che un altro nome con lo stesso spelling nello stesso ambito. Per esempio,

struct s s;

è una dichiarazione valida che dichiara variabili di tipo struct s. Potrebbe non essere una buona pratica, ma i compilatori C devono accettarlo. Non ho mai visto una logica per cui C è stato progettato in questo modo. Ho sempre pensato che fosse un errore, ma è così.

Molti programmatori (incluso il tuo) preferiscono pensare ai nomi di struttura come a nomi di tipo, quindi definiscono un alias per il tag usando un typedef. Ad esempio, definendo

struct s
    {
    ...
    };
typedef struct s S;

ti permette di usare S al posto di struct s, come in

S x;
S *p;

Un programma non può usare S come nome di un tipo e di una variabile (o funzione o costante di enumerazione):

S S;    // error

Questo è buono.

Il nome del tag in una definizione di struct, union o enum è facoltativo. Molti programmatori piegano la definizione della struttura nel typedef e rinunciano del tutto al tag, come in:

typedef struct
    {
    ...
    } S;

L'articolo collegato ha anche una discussione su come il comportamento C ++ di non richiedere un typedefpuò causare problemi di occultamento dei nomi sottili. Per prevenire questi problemi, è una buona idea anche per le typedeftue classi e strutture in C ++, anche se a prima vista sembra non essere necessario. In C ++, con il typedefnome nascosto diventa un errore di cui ti parla il compilatore piuttosto che una fonte nascosta di potenziali problemi.

L'uso di a typedefevita di dover scrivere structogni volta che dichiari una variabile di quel tipo:

struct elem
{
 int i;
 char k;
};
elem user; // compile error!
struct elem user; // this is correct

Un altro buon motivo per scrivere sempre enumerazioni e strutture risulta da questo problema:

enum EnumDef
{
  FIRST_ITEM,
  SECOND_ITEM
};

struct StructDef
{
  enum EnuumDef MyEnum;
  unsigned int MyVar;
} MyStruct;

Notare il refuso in EnumDef nella struttura (Enu u mDef)? Questo viene compilato senza errori (o avvisi) ed è (a seconda dell'interpretazione letterale dello standard C) corretto. Il problema è che ho appena creato una nuova definizione di enumerazione (vuota) all'interno della mia struttura. Non sto (come previsto) usando la definizione precedente EnumDef.

Con un typdef un simile tipo di errori di battitura avrebbe comportato errori del compilatore per l'utilizzo di un tipo sconosciuto:

typedef 
{
  FIRST_ITEM,
  SECOND_ITEM
} EnumDef;

typedef struct
{
  EnuumDef MyEnum; /* compiler error (unknown type) */
  unsigned int MyVar;
} StructDef;
StrructDef MyStruct; /* compiler error (unknown type) */

Vorrei sostenere SEMPRE strutture ed enumerazioni dattiloscritte.

Non solo per salvare un po 'di battitura (nessun gioco di parole previsto;)), ma perché è più sicuro.

Stile di codifica del kernel Linux Il capitolo 5 offre grandi vantaggi e svantaggi (principalmente contro) dell'uso typedef.

Per favore, non usare cose come "vps_t".

È un errore usare typedef per strutture e puntatori. Quando vedi a

vps_t a;

nella fonte, cosa significa?

Al contrario, se dice

struct virtual_container *a;

puoi effettivamente dire cos'è "a".

Molte persone pensano che dattilografia "aiuti la leggibilità". Non così. Sono utili solo per:

(a) oggetti totalmente opachi (dove il typedef è attivamente usato per nascondersi ciò che l'oggetto è).

Esempio: "pte_t" ecc. Oggetti opachi a cui è possibile accedere solo utilizzando le funzioni di accesso appropriate.

NOTA! Opacità e "funzioni accessorie" non sono buone in se stesse. Il motivo per cui li abbiamo per cose come pte_t ecc. È che ci sono davvero zero informazioni accessibili in modo portabile lì.

(b) Cancella tipi interi, in cui l'astrazione aiuta a evitare confusione se è "int" o "lungo".

u8 / u16 / u32 sono dattiloscritti perfettamente fini, sebbene rientrino nella categoria (d) meglio di qui.

NOTA! Ancora una volta - ci deve essere una ragione per questo. Se qualcosa è "unsigned long", non c'è motivo di farlo

typedef unsigned long myflags_t;

ma se c'è una chiara ragione per cui in determinate circostanze potrebbe essere un "unsigned int" e in altre configurazioni potrebbe essere "unsigned long", allora vai avanti e usa un typedef.

(c) quando si usa sparse per creare letteralmente un nuovo tipo per il controllo del tipo.

(d) Nuovi tipi identici ai tipi C99 standard, in determinate circostanze eccezionali.

Anche se ci vorrebbe solo una breve quantità di tempo per abituare gli occhi e il cervello ai tipi standard come 'uint32_t', alcune persone si oppongono comunque al loro uso.

Pertanto, sono consentiti i tipi "u8 / u16 / u32 / u64" specifici di Linux e i loro equivalenti firmati che sono identici ai tipi standard, sebbene non siano obbligatori nel nuovo codice personale.

Quando si modifica il codice esistente che utilizza già l'uno o l'altro set di tipi, è necessario conformarsi alle scelte esistenti in quel codice.

(e) Tipi sicuri per l'uso nello spazio utente.

In alcune strutture che sono visibili allo spazio utente, non possiamo richiedere i tipi C99 e non possiamo usare il modulo 'u32' sopra. Pertanto, usiamo __u32 e tipi simili in tutte le strutture condivise con userspace.

Forse ci sono anche altri casi, ma la regola dovrebbe fondamentalmente essere quella di NON MAI MAI MAI usare un typedef a meno che non sia possibile abbinare chiaramente una di quelle regole.

In generale, un puntatore o una struttura che ha elementi a cui si può ragionevolmente accedere direttamente non dovrebbe mai essere un refuso.

Si scopre che ci sono pro e contro. Un'utile fonte di informazioni è il libro fondamentale "Expert C Programming" ( Capitolo 3 ). In breve, in C hai più spazi dei nomi: tag, tipi, nomi dei membri e identificatori . typedefintroduce un alias per un tipo e lo localizza nello spazio dei nomi dei tag. Vale a dire,

typedef struct Tag{
...members...
}Type;

definisce due cose. Un tag nello spazio dei nomi dei tag e un tipo nello spazio dei nomi dei tipi. Così si può fare entrambe le cose Type myTypee struct Tag myTagType. Dichiarazioni simili struct Type myTypeo Tag myTagTypeillegali. Inoltre, in una dichiarazione come questa:

typedef Type *Type_ptr;

definiamo un puntatore al nostro Tipo. Quindi se dichiariamo:

Type_ptr var1, var2;
struct Tag *myTagType1, myTagType2;

quindi var1, var2e myTagType1sono puntatori a Tipo ma myTagType2non.

Nel libro sopra menzionato, menziona che le strutture di battitura a macchina non sono molto utili in quanto salva il programmatore solo dalla scrittura della parola struct. Tuttavia, ho un'obiezione, come molti altri programmatori C. Anche se a volte si trasforma in offuscamento di alcuni nomi (ecco perché non è consigliabile in basi di codice di grandi dimensioni come il kernel) quando si desidera implementare il polimorfismo in C, aiuta molto a cercare qui i dettagli . Esempio:

typedef struct MyWriter_t{
    MyPipe super;
    MyQueue relative;
    uint32_t flags;
...
}MyWriter;

tu puoi fare:

void my_writer_func(MyPipe *s)
{
    MyWriter *self = (MyWriter *) s;
    uint32_t myFlags = self->flags;
...
}

Quindi puoi accedere a un membro esterno ( flags) dalla struttura interna ( MyPipe) attraverso il casting. Per me è meno confuso lanciare l'intero tipo che farlo (struct MyWriter_ *) s;ogni volta che si desidera eseguire tale funzionalità. In questi casi, un breve riferimento è molto importante soprattutto se si utilizza fortemente la tecnica nel proprio codice.

Infine, l'ultimo aspetto con i typedeftipi di ed è l'incapacità di estenderli, in contrasto con le macro. Se ad esempio hai:

#define X char[10] or
typedef char Y[10]

puoi quindi dichiarare

unsigned X x; but not
unsigned Y y;

Non ci interessa davvero per le strutture perché non si applica agli specificatori di archiviazione ( volatilee const).

Non credo che le dichiarazioni a termine siano neppure possibili con typedef. L'uso di struct, enum e union consente l'inoltro di dichiarazioni quando le dipendenze (a conoscenza) sono bidirezionali.

Stile: l'uso di typedef in C ++ ha abbastanza senso. Può quasi essere necessario quando si tratta di modelli che richiedono parametri multipli e / o variabili. Il typedef aiuta a mantenere la denominazione corretta.

Non così nel linguaggio di programmazione C. L'uso di typedef molto spesso non ha altro scopo se non quello di offuscare l'utilizzo della struttura dei dati. Poiché per dichiarare un tipo di dati vengono utilizzati solo {struct (6), enum (4), union (5)} numero di tasti, non è quasi utile per l'aliasing della struttura. Questo tipo di dati è un'unione o una struttura? L'uso della semplice dichiarazione non tipizzata ti consente di sapere subito di che tipo è.

Notate come Linux viene scritto con il rigoroso elusione di questo aliasing typedef senza senso. Il risultato è uno stile minimalista e pulito.

Cominciamo con le basi e procediamo verso l'alto.

Ecco un esempio di definizione della struttura:

struct point
  {
    int x, y;
  };

Qui il nome pointè facoltativo.

Una struttura può essere dichiarata durante la sua definizione o dopo.

Dichiarazione durante la definizione

struct point
  {
    int x, y;
  } first_point, second_point;

Dichiarazione dopo la definizione

struct point
  {
    int x, y;
  };
struct point first_point, second_point;

Ora, nota attentamente l'ultimo caso sopra; devi scrivere struct pointper dichiarare Strutture di quel tipo se decidi di creare quel tipo in un secondo momento nel tuo codice.

Enter typedef. Se hai intenzione di creare una nuova struttura (Structure è un tipo di dati personalizzato) in un secondo momento nel tuo programma usando lo stesso modello, usarlo typedefdurante la sua definizione potrebbe essere una buona idea poiché puoi salvare un po 'di battitura andando avanti.

typedef struct point
  {
    int x, y;
  } Points;

Points first_point, second_point;

Un avvertimento durante la denominazione del tipo personalizzato

Nulla ti impedisce di utilizzare il suffisso _t alla fine del nome del tipo personalizzato, ma lo standard POSIX si riserva l'uso del suffisso _t per indicare i nomi dei tipi di libreria standard.

il nome che (facoltativamente) dai alla struttura è chiamato nome del tag e, come è stato notato, non è un tipo in sé. Per arrivare al tipo è necessario il prefisso struct.

GTK + a parte, non sono sicuro che il tagname sia usato come qualcosa di simile al typedef al tipo di struttura, quindi in C ++ questo è riconosciuto e puoi omettere la parola chiave struct e usare anche il tagname come nome del tipo:

    struct MyStruct
    {
      int i;
    };

    // The following is legal in C++:
    MyStruct obj;
    obj.i = 7;

typedef non fornirà un insieme co-dipendente di strutture di dati. Questo non si può fare con typdef:

struct bar;
struct foo;

struct foo {
    struct bar *b;
};

struct bar {
    struct foo *f;
};

Ovviamente puoi sempre aggiungere:

typedef struct foo foo_t;
typedef struct bar bar_t;

Qual è esattamente il punto di ciò?

A> a typdef aiuta nel significato e nella documentazione di un programma consentendo la creazione di sinonimi più significativi per i tipi di dati . Inoltre, aiutano a parametrizzare un programma contro i problemi di portabilità (K&R, pg147, C prog lang).

B> una struttura definisce un tipo . Structs consente un raggruppamento conveniente di una raccolta di var per comodità di gestione (K&R, pg127, lingua prog.) Come una singola unità

C> la battitura a macchina di una struttura è spiegata in A sopra.

D> Per me, le strutture sono tipi o contenitori personalizzati o raccolte o spazi dei nomi o tipi complessi, mentre un typdef è solo un mezzo per creare più soprannomi.

Si scopre che è richiesto typedef C99. È obsoleto, ma molti strumenti (ala HackRank) usano c99 come sua pura implementazione in C. E typedef è richiesto lì.

Non sto dicendo che dovrebbero cambiare (forse hanno due opzioni C) se il requisito è cambiato, quelli di noi che studiano per le interviste sul sito sarebbero SOL.

Nel linguaggio di programmazione "C" la parola chiave "typedef" viene utilizzata per dichiarare un nuovo nome per alcuni oggetti (struct, array, function..enum type). Ad esempio, userò una 'struct-s'. In "C" spesso dichiariamo una "struttura" al di fuori della funzione "principale". Per esempio:

struct complex{ int real_part, img_part }COMPLEX;

main(){

 struct KOMPLEKS number; // number type is now a struct type
 number.real_part = 3;
 number.img_part = -1;
 printf("Number: %d.%d i \n",number.real_part, number.img_part);

}

Ogni volta che decido di utilizzare un tipo di struttura, ho bisogno di questa parola chiave "struct" qualcosa "" nome "." Typedef "rinominerà semplicemente quel tipo e posso usare quel nuovo nome nel mio programma ogni volta che voglio. Quindi il nostro codice sarà:

typedef struct complex{int real_part, img_part; }COMPLEX;
//now COMPLEX is the new name for this structure and if I want to use it without
// a keyword like in the first example 'struct complex number'.

main(){

COMPLEX number; // number is now the same type as in the first example
number.real_part = 1;
number.img)part = 5;
printf("%d %d \n", number.real_part, number.img_part);

}

Se hai qualche oggetto locale (struct, array, prezioso) che verrà utilizzato nell'intero programma, puoi semplicemente assegnargli un nome usando un 'typedef'.

A tutti, in linguaggio C, struct / union / enum sono macroistruzione elaborate dal preprocessore del linguaggio C (non confondere con il preprocessore che tratta "#include" e altri)

così :

struct a
{
   int i;
};

struct b
{
   struct a;
   int i;
   int j;
};

la struttura b viene spesa come questa:

struct b
{
    struct a
    {
        int i;
    };
    int i;
    int j;
}

e così, in fase di compilazione, si evolve in pila come qualcosa del tipo: b: int ai int i int j

questo è anche il motivo per cui è difficile avere strutture autoreferenti, preprocessore C arrotondato in un ciclo di dichiarazione che non può terminare.

typedef è un identificatore di tipo, ciò significa che solo il compilatore C lo elabora e può fare come vuole per ottimizzare l'implementazione del codice assembler. Inoltre, non spende membri di tipo par stupidamente come fanno i preprocessori con le strutture ma usa algoritmi di costruzione di riferimento più complessi, quindi costruzioni come:

typedef struct a A; //anticipated declaration for member declaration

typedef struct a //Implemented declaration
{
    A* b; // member declaration
}A;

è consentito e perfettamente funzionante. Questa implementazione dà anche accesso alla conversione del tipo di compilatore e rimuove alcuni effetti di bugging quando il thread di esecuzione lascia il campo di applicazione delle funzioni di inizializzazione.

Ciò significa che in C i typedef sono più vicini alla classe C ++ che alle strutture solitarie.