Я видел много программ, состоящих из структур, подобных приведенной ниже

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

elem user;

Почему это нужно так часто? Любая конкретная причина или область применения?

Как сказал Грег Хьюгилл, typedef означает, что вам больше не нужно писать structвезде. Это не только экономит нажатия клавиш, но также может сделать код чище, так как обеспечивает большую абстракцию.

Вещи как

typedef struct {
  int x, y;
} Point;

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

становится чище, когда вам не нужно видеть ключевое слово "struct" повсюду, это выглядит так, как будто на вашем языке действительно есть тип "Point". Что, после typedef, это тот случай, я думаю.

Также обратите внимание, что хотя ваш пример (и мой) опускает именование самого struct себя, на самом деле именование это также полезно, когда вы хотите предоставить непрозрачный тип. Тогда у вас будет такой код в заголовке, например:

typedef struct Point Point;

Point * point_new(int x, int y);

а затем предоставить struct определение в файле реализации:

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

В этом последнем случае вы не можете вернуть Point по значению, так как его определение скрыто от пользователей заголовочного файла. Эта техника широко используется вНапример, GTK + .

ОБНОВЛЕНИЕ Обратите внимание, что существуют также высоко оцененные C-проекты, в которых использование typedefскрытия structсчитается плохой идеей, ядро ​​Linux, вероятно, является наиболее известным таким проектом. См. Главу 5 документа Linux Kernel CodingStyle для злых слов Линуса. :) Моя точка зрения заключается в том, что «следует» в вопросе, возможно, не в камне, в конце концов.

Удивительно, как много людей ошибаются. ПОЖАЛУЙСТА, не печатайте структуры типов в C, это излишне загрязняет глобальное пространство имен, которое обычно очень сильно загрязняется уже в больших программах на C.

Кроме того, структуры typedef'd без имени тега являются основной причиной ненужного наложения отношений упорядочения между заголовочными файлами.

Рассматривать:

#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

С таким определением, не используя typedefs, модуль compiland может включить foo.h, чтобы получить FOO_DEFопределение. Если он не пытается разыменовать член 'bar' fooструктуры, тогда нет необходимости включать файл 'bar.h'.

Кроме того, поскольку пространства имен различаются между именами тегов и именами членов, можно написать очень читаемый код, такой как:

struct foo *foo;

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

Поскольку пространства имен являются отдельными, нет никакого конфликта в именовании переменных, совпадающих с их именем тега struct.

Если мне придется поддерживать ваш код, я удалю ваши структуры typedef'd.

Из старой статьи Дэна Сакса ( http://www.ddj.com/cpp/184403396?pgno=3 ):

Правила языка C для структур именования немного эксцентричны, но они довольно безобидны. Однако, когда они распространяются на классы в C ++, те же самые правила открывают небольшие трещины для обхода ошибок.

В С, имя появляется в

struct s
    {
    ...
    };

это тег Имя тега не является именем типа. Учитывая определение выше, такие объявления, как

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

ошибки в C. Вы должны написать их как

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

Имена союзов и перечислений также являются тегами, а не типами.

В C теги отличаются от всех других имен (для функций, типов, переменных и констант перечисления). Компиляторы C поддерживают теги в таблице символов, которая концептуально, если не физически отделена от таблицы, которая содержит все другие имена. Таким образом, для программы на Си возможно иметь тег и другое имя с одинаковым написанием в одной и той же области видимости. Например,

struct s s;

является допустимым объявлением, которое объявляет переменную s типа struct s. Это может не быть хорошей практикой, но компиляторы C должны принять это. Я никогда не видел обоснования того, почему C был разработан таким образом. Я всегда думал, что это ошибка, но это так.

Многие программисты (в том числе и ваши) предпочитают воспринимать имена структур как имена типов, поэтому они определяют псевдоним для тега, используя typedef. Например, определяя

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

позволяет использовать S вместо структуры S, как в

S x;
S *p;

Программа не может использовать S в качестве имени как типа, так и переменной (или функции, или константы перечисления):

S S;    // error

Это хорошо.

Имя тега в определении структуры, объединения или перечисления является необязательным. Многие программисты складывают определение структуры в typedef и вообще обходятся без тега, как в:

typedef struct
    {
    ...
    } S;

В связанной статье также обсуждается, как поведение C ++, не требующее a, typedefможет вызывать тонкие проблемы со скрытием имен. Чтобы предотвратить эти проблемы, это хорошая идея для typedefваших классов и структур в C ++, даже если на первый взгляд это кажется ненужным. В C ++ typedefскрытие имени становится ошибкой, о которой говорит вам компилятор, а не скрытым источником потенциальных проблем.

Использование typedefизбегает необходимости писать structкаждый раз, когда вы объявляете переменную этого типа:

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

Еще одна веская причина, чтобы всегда указывать перечисления и структуры, вытекает из этой проблемы:

enum EnumDef
{
  FIRST_ITEM,
  SECOND_ITEM
};

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

Обратите внимание на опечатку в EnumDef в структуре (Enu u Enu mDef)? Он компилируется без ошибок (или предупреждений) и является (в зависимости от буквальной интерпретации стандарта C) правильным. Проблема в том, что я только что создал новое (пустое) определение перечисления в моей структуре. Я не использую (как предполагалось) предыдущее определение EnumDef.

С typedef подобного рода опечатки привели бы к ошибкам компилятора для использования неизвестного типа:

typedef 
{
  FIRST_ITEM,
  SECOND_ITEM
} EnumDef;

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

Я бы поддержал ВСЕГДА набирать структуры и перечисления.

Не только для того, чтобы сохранить некоторую печать (не каламбур;)), но и потому, что это безопаснее.

Стиль кодирования ядра Linux Глава 5 дает большие плюсы и минусы (в основном минусы) использования typedef.

Пожалуйста, не используйте такие вещи, как "vps_t".

Это ошибка использовать ЬурейеЕ для структур и указателей. Когда вы видите

vps_t a;

в источнике что это значит?

Напротив, если это говорит

struct virtual_container *a;

Вы действительно можете сказать, что такое «а».

Многие думают, что typedefs "помогает читабельности". Не так. Они полезны только для:

(а) полностью непрозрачные объекты (где typedef активно используется, чтобы скрыть, что это за объект).

Пример: "pte_t" и т. Д. Непрозрачные объекты, доступ к которым можно получить только с помощью соответствующих функций доступа.

НОТА! Непрозрачность и «функции доступа» сами по себе не годятся. Причина, по которой мы их используем для таких вещей, как pte_t и т. Д., Заключается в том, что в действительности там абсолютно нулевая доступная информация.

(б) Ясные целочисленные типы, где абстракция помогает избежать путаницы, является ли она «int» или «long».

u8 / u16 / u32 - отличные определения типов, хотя они вписываются в категорию (d) лучше, чем здесь.

НОТА! Опять же - должна быть причина для этого. Если что-то "unsigned long", то нет причин делать

typedef unsigned long myflags_t;

но если есть явная причина того, почему в определенных обстоятельствах это может быть «unsigned int», а в других конфигурациях может быть «unsigned long», тогда непременно продолжайте и используйте typedef.

(c) когда вы используете sparse для буквального создания нового типа для проверки типов.

(d) Новые типы, идентичные стандартным типам C99, в определенных исключительных обстоятельствах.

Хотя глазам и мозгу понадобится совсем немного времени, чтобы привыкнуть к стандартным типам, таким как 'uint32_t', некоторые люди все равно возражают против их использования.

Следовательно, специфичные для Linux типы «u8 / u16 / u32 / u64» и их подписанные эквиваленты, которые идентичны стандартным типам, разрешены, хотя они не являются обязательными в новом собственном коде.

При редактировании существующего кода, который уже использует тот или иной набор типов, вы должны соответствовать существующим вариантам в этом коде.

(e) Типы, безопасные для использования в пользовательском пространстве.

В некоторых структурах, которые видимы для пользовательского пространства, мы не можем требовать типов C99 и не можем использовать форму «u32» выше. Таким образом, мы используем __u32 и подобные типы во всех структурах, которые используются совместно с пользовательским пространством.

Может быть, есть и другие случаи, но правило должно быть НИКОГДА не использовать typedef, если вы не можете четко соответствовать одному из этих правил.

В общем случае указатель или структура, в которой есть элементы, к которым можно получить непосредственный доступ, никогда не должна быть typedef.

Оказывается, есть плюсы и минусы. Полезным источником информации является оригинальная книга «Программирование на Expert C» ( глава 3 ). Вкратце, в C у вас есть несколько пространств имен: теги, типы, имена членов и идентификаторы . typedefвводит псевдоним для типа и находит его в пространстве имен тега. А именно,

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

определяет две вещи. Один тег в пространстве имен тегов и один тип в пространстве имен типов. Так что вы можете сделать и то, Type myTypeи другое struct Tag myTagType. Объявления вроде struct Type myTypeили Tag myTagTypeявляются незаконными. Кроме того, в объявлении, как это:

typedef Type *Type_ptr;

мы определяем указатель на наш тип. Итак, если мы объявим:

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

то var1, var2и myTagType1указатели на тип , но myTagType2нет.

В вышеупомянутой книге упоминается, что структуры определения типов не очень полезны, поскольку они только спасают программиста от написания слова struct. Однако у меня есть возражение, как и у многих других программистов на Си. Хотя иногда оказывается необходимым запутывать некоторые имена (именно поэтому это не рекомендуется в больших базах кода, таких как ядро), когда вы хотите реализовать полиморфизм в C, здесь очень много подробностей . Пример:

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

ты можешь сделать:

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

Таким образом, вы можете получить доступ к внешнему члену ( flags) с помощью внутренней структуры ( MyPipe) через приведение. Для меня это менее запутанно приводить весь тип, чем (struct MyWriter_ *) s;каждый раз, когда вы хотите выполнить такую ​​функциональность. В этих случаях краткие ссылки имеют большое значение, особенно если вы интенсивно используете технику в своем коде.

Наконец, последний аспект typedefтипов ed - это невозможность их расширения, в отличие от макросов. Если, например, у вас есть:

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

Вы можете объявить

unsigned X x; but not
unsigned Y y;

Мы на самом деле не заботимся об этом для структур, потому что это не относится к спецификаторам хранения ( volatileи const).

Я не думаю, что предварительные объявления возможны даже с typedef. Использование struct, enum и union позволяет пересылать объявления, когда зависимости (знают о них) являются двунаправленными.

Стиль: использование typedef в C ++ имеет смысл. Это может почти понадобиться при работе с шаблонами, которые требуют нескольких и / или переменных параметров. Typedef помогает сохранить правильное именование.

Не так в языке программирования Си. Использование typedef чаще всего служит не для того, чтобы запутать использование структуры данных. Поскольку только {struct (6), enum (4), union (5)} количество нажатий клавиш используются для объявления типа данных, практически нет смысла использовать псевдонимы структуры. Это тип данных объединение или структура? Использование простого не типизированного объявления позволяет сразу узнать, какой это тип.

Обратите внимание, как Linux написан со строгим избеганием этого псевдонима. Результат - минималистский и чистый стиль.

Давайте начнем с основ и продолжим наш путь.

Вот пример определения структуры:

struct point
  {
    int x, y;
  };

Здесь название pointне обязательно.

Структура может быть объявлена ​​во время ее определения или после.

Объявление во время определения

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

Декларирование после определения

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

Теперь внимательно обратите внимание на последний случай выше; вам нужно написать, struct pointчтобы объявить структуры этого типа, если вы решите создать этот тип на более позднем этапе вашего кода.

Введите typedef. Если вы намереваетесь создать новую структуру (структура - это пользовательский тип данных) позже в вашей программе, используя тот же план, использование typedefво время ее определения может быть хорошей идеей, так как вы можете сохранить некоторую печать в дальнейшем.

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

Points first_point, second_point;

Слово предостережения при названии вашего пользовательского типа

Ничто не мешает вам использовать суффикс _t в конце имени пользовательского типа, но стандарт POSIX оставляет за собой использование суффикса _t для обозначения имен стандартных библиотечных типов.

имя, которое вы (необязательно) даете структуре, называется именем тега и, как было отмечено, само по себе не является типом. Чтобы добраться до типа, требуется префикс структуры.

Помимо GTK +, я не уверен, что тэг используется так же часто, как typedef для типа структуры, поэтому в C ++ это распознается, и вы можете опустить ключевое слово struct и использовать тэг в качестве имени типа:

    struct MyStruct
    {
      int i;
    };

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

typedef не будет предоставлять взаимозависимый набор структур данных. Это вы не можете сделать с typdef:

struct bar;
struct foo;

struct foo {
    struct bar *b;
};

struct bar {
    struct foo *f;
};

Конечно, вы всегда можете добавить:

typedef struct foo foo_t;
typedef struct bar bar_t;

В чем именно смысл этого?

A> typdef помогает в значении и документировании программы, позволяя создавать более значимые синонимы для типов данных . Кроме того, они помогают параметризовать программу против проблем переносимости (K & R, pg147, C prog lang).

B> структура определяет тип . Structs позволяет удобно группировать коллекцию переменных для удобства обработки (K & R, pg127, C prog lang.) Как единое целое.

C> typedef'ing структура объяснена в A выше.

D> Для меня структуры - это пользовательские типы, контейнеры, коллекции, пространства имен или сложные типы, тогда как typdef - это просто средство для создания дополнительных псевдонимов.

Оказывается, в C99 typedef не требуется. Он устарел, но многие инструменты (а-ля HackRank) используют c99 в качестве чистой реализации на C. И typedef требуется там.

Я не говорю, что они должны измениться (возможно, иметь два варианта C), если требование изменилось, те из нас, кто готовится к интервью на сайте, будут SOL.

В языке программирования «C» ключевое слово «typedef» используется для объявления нового имени для некоторого объекта (структура, массив, тип функции… типа). Например, я буду использовать struct-s. В «C» мы часто объявляем «struct» вне функции «main». Например:

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

}

Каждый раз, когда я решу использовать тип структуры, мне понадобится ключевое слово struct что-то имя, typedef просто переименует этот тип, и я могу использовать это новое имя в своей программе каждый раз, когда захочу. Итак, наш код будет:

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

}

Если у вас есть какой-то локальный объект (структура, массив, ценность), который будет использоваться во всей вашей программе, вы можете просто дать ему имя, используя typedef.

Вообще говоря, в языке C struct / union / enum - это макроинструкция, обрабатываемая препроцессором языка C (не путайте с препроцессором, который обрабатывает "#include" и другие)

так :

struct a
{
   int i;
};

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

структура b расходуется примерно так:

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

и так, во время компиляции он развивается в стеке как-то так: b: int ai int i int j

поэтому также трудно иметь самоссылающиеся структуры, препроцессор C в цикле объявления, который не может завершиться.

typedef - это спецификатор типа, это означает, что его обрабатывает только компилятор C, и он может делать то, что хочет для оптимизации реализации ассемблерного кода. Он также не тратит членов типа par тупо, как это делает препроцессор со структурами, но использует более сложный алгоритм построения ссылок, поэтому конструкция выглядит так:

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

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

разрешен и полностью функционален. Эта реализация предоставляет также доступ к преобразованию типов компилятора и устраняет некоторые эффекты ошибок, когда поток выполнения покидает поле приложения функций инициализации.

Это означает, что в C typedefs ближе к классу C ++, чем к одиноким структурам.