Widziałem wiele programów składających się ze struktur takich jak ten poniżej

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

elem user;

Dlaczego jest tak często potrzebny? Czy jest jakiś konkretny powód lub odpowiedni obszar?

Jak powiedział Greg Hewgill, typedef oznacza, że ​​nie musisz już pisać structwszędzie. To nie tylko oszczędza naciśnięcia klawiszy, ale także może uczynić kod czystszym, ponieważ zapewnia smidgen więcej abstrakcji.

Rzeczy jak

typedef struct {
  int x, y;
} Point;

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

staje się czystszy, gdy nie musisz widzieć słowa kluczowego „struct” w całym miejscu, wygląda to tak, jakby naprawdę istniał typ o nazwie „Punkt” w twoim języku. Co, jak typedefsądzę , po tym jest.

Zauważ też, że chociaż twój przykład (i mój) pomijał nazywanie struct samego siebie, tak naprawdę nazywanie go jest również przydatne, gdy chcesz podać nieprzejrzysty typ. W nagłówku miałbyś taki kod, na przykład:

typedef struct Point Point;

Point * point_new(int x, int y);

a następnie podaj structdefinicję w pliku implementacji:

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;
}

W tym ostatnim przypadku nie można zwrócić punktu według wartości, ponieważ jego definicja jest ukryta przed użytkownikami pliku nagłówka. Jest to na przykład technika szeroko stosowana w GTK + .

AKTUALIZACJA Zauważ, że istnieją również wysoko cenione projekty C, w których użycie typedefukrywania structjest uważane za zły pomysł, jądro Linuksa jest prawdopodobnie najbardziej znanym takim projektem. Zobacz rozdział 5 dokumentu Linux Kernel CodingStyle, aby dowiedzieć się o gniewnych słowach Linusa. :) Chodzi mi o to, że pytanie „powinno” w pytaniu może nie jest w końcu osadzone w kamieniu.

To niesamowite, jak wielu ludzi się myli. PROSZĘ nie wpisuj struktur w C, niepotrzebnie zanieczyszcza globalną przestrzeń nazw, która jest zwykle bardzo zanieczyszczona już w dużych programach C.

Struktury typedef'd bez nazwy znacznika są główną przyczyną niepotrzebnego narzucania relacji porządkowania między plikami nagłówkowymi.

Rozważać:

#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

Przy takiej definicji, bez użycia typedefs, możliwe jest, że jednostka kompilandowa będzie zawierać foo.h, aby uzyskać FOO_DEFdefinicję. Jeśli nie spróbuje wyłuskać elementu „bar” foostruktury, wówczas nie będzie potrzeby dołączania pliku „bar.h”.

Ponadto, ponieważ przestrzenie nazw różnią się między nazwami znaczników a nazwami członków, możliwe jest napisanie bardzo czytelnego kodu, takiego jak:

struct foo *foo;

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

Ponieważ przestrzenie nazw są oddzielne, nie ma konfliktu w nazwach zmiennych zgodnych z nazwą ich znacznika struct.

Jeśli będę musiał zachować twój kod, usunę twoje strukturalne typy.

Ze starego artykułu Dana Saksa ( http://www.ddj.com/cpp/184403396?pgno=3 ):

Zasady języka C dla nazewnictwa struktur są trochę ekscentryczne, ale są całkiem nieszkodliwe. Jednak po rozszerzeniu na klasy w C ++ te same reguły otwierają małe pęknięcia, przez które mogą się czołgać błędy.

W C nazwa pojawia się w

struct s
    {
    ...
    };

jest tagiem. Nazwa znacznika nie jest nazwą typu. Biorąc pod uwagę powyższą definicję, deklaracje takie jak

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

są błędami w C. Musisz je zapisać jako

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

Nazwy związków i wyliczenia są również znacznikami, a nie typami.

W C znaczniki różnią się od wszystkich innych nazw (dla funkcji, typów, zmiennych i stałych wyliczenia). Kompilatory C utrzymują znaczniki w tabeli symboli, która koncepcyjnie, jeśli nie jest fizycznie oddzielona od tabeli, która zawiera wszystkie inne nazwy. Dlatego możliwe jest, że program C ma zarówno znacznik, jak i inną nazwę o tej samej pisowni w tym samym zakresie. Na przykład,

struct s s;

jest poprawną deklaracją deklarującą zmienną typu struct s. To może nie być dobra praktyka, ale kompilatory C muszą to zaakceptować. Nigdy nie widziałem uzasadnienia, dlaczego C został zaprojektowany w ten sposób. Zawsze myślałem, że to pomyłka, ale jest.

Wielu programistów (w tym naprawdę) wolą myśleć o nazwach struktur jako nazwach typów, więc definiują alias znacznika za pomocą typedef. Na przykład definiowanie

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

pozwala używać S zamiast struct s, jak w

S x;
S *p;

Program nie może używać S jako nazwy zarówno typu, jak i zmiennej (lub funkcji lub stałej wyliczenia):

S S;    // error

To jest dobre.

Nazwa znacznika w definicji struct, union lub enum jest opcjonalna. Wielu programistów składa definicję struktury na typedef i całkowicie rezygnuje ze znacznika, jak w:

typedef struct
    {
    ...
    } S;

W linkowanym artykule jest także dyskusja na temat tego, jak zachowanie C ++, które nie wymaga, typedefmoże powodować subtelne problemy z ukrywaniem nazw. Aby zapobiec tym problemom, dobrym pomysłem jest także dla typedeftwoich klas i struktur w C ++, nawet jeśli na pierwszy rzut oka wydaje się to niepotrzebne. W C ++ typedefukrywanie nazwy staje się błędem, o którym mówi kompilator, a nie ukrytym źródłem potencjalnych problemów.

Używanie typedefznaku unika konieczności pisania za structkażdym razem, gdy deklarujesz zmienną tego typu:

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

Kolejny dobry powód, aby zawsze wpisywać wyliczenia i struktury wynika z tego problemu:

enum EnumDef
{
  FIRST_ITEM,
  SECOND_ITEM
};

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

Czy zauważyłeś literówkę w EnumDef w struct ( Enu u mDef)? Kompiluje się bez błędu (lub ostrzeżenia) i jest (w zależności od dosłownej interpretacji standardu C) poprawny. Problem polega na tym, że właśnie utworzyłem nową (pustą) definicję wyliczenia w mojej strukturze. Nie używam (zgodnie z zamierzeniami) poprzedniej definicji EnumDef.

W przypadku typdef podobne typy literówek spowodowałyby błędy kompilatora przy użyciu nieznanego typu:

typedef 
{
  FIRST_ITEM,
  SECOND_ITEM
} EnumDef;

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

Zalecałbym ZAWSZE wpisywanie struktur i wyliczeń.

Nie tylko, aby zaoszczędzić trochę pisania (nie ma sensu;)), ale dlatego, że jest bezpieczniejszy.

Styl kodowania jądra Linuksa Rozdział 5 podaje świetne zalety i wady (głównie wady) korzystania typedef.

Nie używaj takich rzeczy jak „vps_t”.

Jest to błędem użycie typedef dla struktur i wskaźników. Gdy zobaczysz a

vps_t a;

co to znaczy w źródle?

Przeciwnie, jeśli to mówi

struct virtual_container *a;

możesz właściwie powiedzieć, co to jest „a”.

Wiele osób uważa, że ​​typedefs „poprawia czytelność”. Skąd. Są przydatne tylko w przypadku:

(a) całkowicie nieprzezroczyste obiekty (gdzie typedef jest aktywnie używany do ukrycia tego, co jest przedmiotem).

Przykład: „pte_t” itp. Nieprzezroczyste obiekty, do których można uzyskać dostęp tylko za pomocą odpowiednich funkcji akcesora.

UWAGA! Nieprzezroczystość i „funkcje akcesora” same w sobie nie są dobre. Powodem, dla którego je mamy dla takich rzeczy jak pte_t itp., Jest to, że naprawdę tam jest absolutnie zero przenośnych informacji.

(b) Wyczyść typy liczb całkowitych, w których abstrakcja pomaga uniknąć nieporozumień, czy jest to „int” czy „long”.

u8 / u16 / u32 są idealnie dobranymi czcionkami, chociaż pasują do kategorii (d) lepiej niż tutaj.

UWAGA! Znowu - musi być ku temu powód . Jeśli coś jest „niepodpisane długo”, nie ma powodu, aby to robić

typedef unsigned long myflags_t;

ale jeśli istnieje wyraźny powód, dla którego w pewnych okolicznościach może to być „bez znaku int”, a w innych konfiguracjach może być „bez znaku długi”, to zdecydowanie skorzystaj z pisma maszynowego.

(c) gdy używasz rzadkiego, aby dosłownie utworzyć nowy typ do sprawdzania typu.

(d) Nowe typy, które są identyczne ze standardowymi typami C99, w pewnych wyjątkowych okolicznościach.

Chociaż oczy i mózg przyzwyczają się do krótkiego czasu przyzwyczajenia się do standardowych typów, takich jak „uint32_t”, niektórzy i tak sprzeciwiają się ich użyciu.

Dlatego specyficzne dla Linuksa typy „u8 / u16 / u32 / u64” i ich podpisane odpowiedniki, które są identyczne ze standardowymi typami, są dozwolone - chociaż nie są obowiązkowe w nowym kodzie.

Podczas edycji istniejącego kodu, który już korzysta z jednego lub drugiego zestawu typów, powinieneś dostosować się do istniejących wyborów w tym kodzie.

(e) Rodzaje bezpieczne do użytku w przestrzeni użytkownika.

W niektórych strukturach widocznych dla przestrzeni użytkownika nie możemy wymagać typów C99 i nie możemy użyć powyższego formularza „u32”. Dlatego używamy __u32 i podobnych typów we wszystkich strukturach współdzielonych z przestrzenią użytkownika.

Być może są też inne przypadki, ale zasadą powinno być NIGDY NIE NIGDY używać typedef, chyba że możesz wyraźnie dopasować jedną z tych reguł.

Zasadniczo wskaźnik lub struktura, która ma elementy, do których można uzyskać bezpośredni dostęp, nigdy nie powinna być czcionką maszynową.

Okazuje się, że są plusy i minusy. Przydatnym źródłem informacji jest przełomowa książka „Expert C Programming” ( rozdział 3 ). W skrócie, w C masz wiele przestrzeni nazw: tagi, typy, nazwy członków i identyfikatory . typedefwprowadza alias dla typu i lokalizuje go w przestrzeni nazw znaczników. Mianowicie,

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

definiuje dwie rzeczy. Jeden znacznik w przestrzeni nazw znaczników i jeden Wpisz w przestrzeni nazw typów. Więc możesz zrobić jedno Type myTypei drugie struct Tag myTagType. Deklaracje takie jak struct Type myTypelub Tag myTagTypesą nielegalne. Ponadto w deklaracji takiej jak ta:

typedef Type *Type_ptr;

definiujemy wskaźnik do naszego typu. Więc jeśli zadeklarujemy:

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

następnie var1, var2i myTagType1są wskaźnikami do Type, ale myTagType2nie.

W wyżej wspomnianej książce wspomina, że ​​struktury do pisania na maszynie nie są zbyt przydatne, ponieważ ratuje programistę przed pisaniem słowa struct. Mam jednak sprzeciw, podobnie jak wielu innych programistów C. Chociaż czasami okazuje się, że niektóre nazwy są zaciemnione (dlatego nie jest wskazane w dużych bazach kodu, takich jak jądro), kiedy chcesz zaimplementować polimorfizm w C, bardzo pomaga tutaj poszukać szczegółów . Przykład:

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

możesz to zrobić:

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

Możesz więc uzyskać dostęp do zewnętrznego elementu ( flags) przez wewnętrzną strukturę ( MyPipe) poprzez rzutowanie. Dla mnie jest mniej mylące, aby przesyłać cały typ niż robić za (struct MyWriter_ *) s;każdym razem, gdy chcesz wykonać taką funkcjonalność. W takich przypadkach krótkie odwoływanie się jest bardzo ważne, szczególnie jeśli mocno stosujesz tę technikę w kodzie.

Wreszcie ostatnim aspektem typedeftypów ed jest brak możliwości ich rozszerzenia, w przeciwieństwie do makr. Jeśli na przykład masz:

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

możesz wtedy zadeklarować

unsigned X x; but not
unsigned Y y;

Tak naprawdę nie dbamy o to dla struktur, ponieważ nie dotyczy to specyfikatorów pamięci ( volatilei const).

Nie sądzę, aby deklaracje typu forward były nawet możliwe w przypadku typedef. Użycie struct, enum i union pozwala na przekazywanie deklaracji, gdy zależności (o których wiadomo) są dwukierunkowe.

Styl: użycie typedef w C ++ ma całkiem sens. Może to być prawie konieczne w przypadku szablonów, które wymagają wielu i / lub zmiennych parametrów. Typedef pomaga zachować prostą nazwę.

Nie w języku programowania C. Użycie typedef najczęściej nie służy celowi, ale zaciemnia użycie struktury danych. Ponieważ tylko liczba klawiszy {{((6), enum (4), union (5)} jest użyta do zadeklarowania typu danych, prawie nie ma zastosowania do aliasingu struktury. Czy ten typ danych jest związkiem czy strukturą? Korzystanie z prostej deklaracji bez czcionek pozwala od razu wiedzieć, jaki to typ.

Zwróć uwagę, jak Linux jest napisany ze ścisłym unikaniem tego nonsensownego aliasingu, jaki przynosi typedef. Rezultatem jest minimalistyczny i czysty styl.

Zacznijmy od podstaw i pracujmy dalej.

Oto przykład definicji struktury:

struct point
  {
    int x, y;
  };

Tutaj nazwa pointjest opcjonalna.

Strukturę można zadeklarować podczas jej definiowania lub później.

Deklaracja podczas definicji

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

Deklaracja po definicji

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

Teraz uważnie zwróć uwagę na ostatni przypadek powyżej; musisz napisać, struct pointaby zadeklarować Struktury tego typu, jeśli zdecydujesz się utworzyć ten typ w późniejszym punkcie kodu.

Enter typedef. Jeśli zamierzasz później utworzyć nową Strukturę (Struktura jest niestandardowym typem danych) w swoim programie przy użyciu tego samego schematu, użycie typedefjej podczas definicji może być dobrym pomysłem, ponieważ możesz zaoszczędzić trochę pisania na maszynie.

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

Points first_point, second_point;

Ostrzegając przy określaniu typu niestandardowego

Nic nie stoi na przeszkodzie, aby używać sufiksu _t na końcu nazwy typu niestandardowego, ale standard POSIX zastrzega użycie sufiksu _t do oznaczania standardowych nazw typów bibliotek.

nazwa, którą (opcjonalnie) nadajesz struktury, nazywa się nazwą znacznika i, jak zauważono, sama w sobie nie jest typem. Aby przejść do tego typu, wymagany jest prefiks struct.

Poza GTK +, nie jestem pewien, czy zmienna jest używana tak często jak typedef do typu struct, więc w C ++, który jest rozpoznawany, możesz pominąć słowo kluczowe struct i użyć również zmiennej jako nazwy typu:

    struct MyStruct
    {
      int i;
    };

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

Typedef nie zapewni współzależnego zestawu struktur danych. Tego nie można zrobić z typdef:

struct bar;
struct foo;

struct foo {
    struct bar *b;
};

struct bar {
    struct foo *f;
};

Oczywiście zawsze możesz dodać:

typedef struct foo foo_t;
typedef struct bar bar_t;

Jaki jest tego sens?

A> typdef pomaga w znaczeniu i dokumentacji programu, umożliwiając tworzenie bardziej znaczących synonimów dla typów danych . Ponadto pomagają sparametryzować program pod kątem problemów związanych z przenośnością (K&R, str. 147, C prog lang).

B> struktura definiuje typ . Struktury umożliwiają wygodne grupowanie kolekcji zmiennych dla wygody obsługi (K&R, pg127, C prog lang.) Jako pojedynczej jednostki

C> typowanie struktury jest wyjaśnione w A powyżej.

D> Dla mnie struktury są niestandardowymi typami lub kontenerami, kolekcjami lub przestrzeniami nazw lub typami złożonymi, podczas gdy typdef to tylko sposób na stworzenie większej liczby pseudonimów.

Okazuje się, że w C99 wymagany jest typedef. Jest przestarzały, ale wiele narzędzi (ala HackRank) używa c99 jako czystej implementacji C. I tam wymagany jest typedef.

Nie twierdzę, że powinni się zmienić (może mieć dwie opcje C), jeśli wymaganie się zmieni, ci z nas, którzy przygotowują się do wywiadów na stronie, byliby SOL.

W języku programowania „C” słowo kluczowe „typedef” służy do zadeklarowania nowej nazwy dla jakiegoś obiektu (struct, tablica, funkcja… typ enum). Na przykład użyję „struct-s”. W „C” często deklarujemy „struct” poza funkcją „main”. Na przykład:

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);

}

Za każdym razem, gdy decyduję się na użycie typu struktury, będę potrzebować tego słowa kluczowego „struct” coś „„ nazwa ”.„ Typedef ”po prostu zmieni nazwę tego typu i będę mógł używać tej nowej nazwy w moim programie za każdym razem, gdy chcę. Nasz kod będzie więc:

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);

}

Jeśli masz jakiś obiekt lokalny (struct, tablica, wartościowy), który będzie używany w całym programie, możesz po prostu nadać mu nazwę, używając „typedef”.

W ogóle w języku C struct / union / enum są makropoleceniami przetwarzanymi przez preprocesor języka C (nie myl się z preprocesorem, który traktuje „#include” i inne)

więc :

struct a
{
   int i;
};

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

Struktura b jest wydana jako coś takiego:

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

i tak w czasie kompilacji ewoluuje na stosie jako coś w rodzaju: b: int ai int i int j

dlatego też trudno jest mieć samoreferencyjne struktury, rundę preprocesora C w pętli deklaracji, która nie może się zakończyć.

typedef są specyfikatorem typu, co oznacza, że ​​przetwarzany jest tylko przez kompilator C i może on robić, co chce, w celu optymalizacji implementacji kodu asemblera. Nie wydaje też członka typu par głupio, tak jak preprocesor robi ze strukturami, ale używa bardziej złożonego referencyjnego algorytmu konstrukcji, więc konstrukcja taka jak:

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

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

jest dozwolone i w pełni funkcjonalne. Ta implementacja daje również dostęp do konwersji typu kompilatora i usuwa niektóre efekty błędów, gdy wątek wykonania opuszcza pole aplikacji funkcji inicjalizacji.

Oznacza to, że w C typedefs są bardziej zbliżone do klasy C ++ niż samotne struktury.