Более подробный и точный ответ: stackoverflow.com/questions/612328/…

У него есть недостатки, я думаю, вы не можете создать список ссылок с анонимной структурой, потому что строка struct * ptr внутри структуры вызовет ошибку

«Более подробный и точный ответ» - Разница между struct и typedef struct в C++, и между C и C++ есть существенные различия в этой области, которые делают этот ответ не совсем подходящим для вопроса о C.

У этого вопроса есть дубликат typedef struct vs struct определения, на который также есть звездные ответы.

OTOH, kernel.org/doc/html/v4.10/process/coding-style.html говорит нам, что мы не должны делать такие определения типов.

хорошо, у нас нет этой проблемы в C++. Так почему бы никому не удалить этот сбой из компилятора C и не сделать его таким же, как в C++. Хорошо, у C++ есть несколько разных областей приложения, и поэтому он имеет расширенные функции. Но можем ли мы не унаследовать некоторые из них в C, не изменив оригинальный C?

Manoj, имя тега ("struct foo") необходимо, когда вам нужно определить структуру, которая ссылается на себя. например указатель «следующий» в связанном списке. Более того, компилятор реализует стандарт, и это то, что стандарт предписывает делать.

Это не глюк в компиляторе C, это часть дизайна. Они изменили это для C++, что, я думаю, упрощает задачу, но это не означает, что поведение C неправильное.

к сожалению, многие `` программисты '' определяют структуру, а затем typedef ее с каким-то `` несвязанным '' именем (например, struct myStruct ...; typedef struct myStruct susan *; почти во всех случаях typedef приводит только к загромождению кода, скрывая фактическое определение переменная / параметр и вводит в заблуждение всех, включая автора исходного кода.

@ user3629249 Я согласен с вами, что упомянутый стиль программирования ужасен, но это не повод очернять структуры typedef в целом. Вы также можете сделать typedef struct foo foo;. Конечно, ключевое слово struct не требуется больше, чем может быть полезным намеком на то, что псевдоним типа, который мы рассматриваем, является псевдонимом для структуры, но в целом это неплохо. Рассмотрим также случай, когда идентификатор результирующего псевдонима типа typedef указывает, что это псевдоним для структуры, например: typedef struct foo foo_struct;.

Вы не должны использовать идентификаторы с подчеркиванием, за которым следует заглавная буква, они зарезервированы (см. Раздел 7.1.3, абзац 1). Хотя вряд ли это будет большой проблемой, это технически неопределенное поведение при их использовании (7.1.3, параграф 2).

Как насчет плюсов и минусов этого синтаксиса: typedef struct Point {int x, y; } Укажите эту ссылку: en.wikipedia.org/wiki/Struct_(C_programming_language)#typede‌ f обсуждает проблему, но не дает однозначного ответа на вопрос, в пользу она или нет.

Ответ на мой вопрос: stackoverflow.com/questions/1110944/…

@dreamlax: на случай, если это было непонятно другим, это только начало - идентификатор с подчеркиванием и верхним регистром, которого вы не должны делать; вы можете использовать это в середине идентификатора.

Интересно, что приведенный здесь пример (в котором typedef предотвращает использование «struct» «повсюду») на самом деле длиннее, чем тот же код без typedef, поскольку он сохраняет ровно одно использование слова «struct». Немного абстракции редко можно сравнить с дополнительной обфускацией.

@WilliamPursell Как вы считаете, чтобы получить один? Я вижу троих; один в заголовке и два в файле реализации. Может я просто запуталась.

@unwind Прошло много месяцев, поэтому я не могу точно сказать, о чем думал, и согласен с вашим подсчетом. Возможно, я думал о следующем очень плохом стиле: заголовочный файл только с struct point * point_new(int x, int y); (объединение прямого объявления структуры с объявлением функции) и файл реализации struct point { int x,y; } * point_new( ... (объединение определения структуры с объявлением функции).

@dreamlax Напомню, что многие коды Gstreamer определяют структуры с псевдонимом по шаблону _ [A-Z]. * ... И это работает очень хорошо. Не могли бы вы объяснить еще немного (ссылка в комментарии меня удовлетворила бы). Кстати, извините за "некромантинг"

@Rerito: Обычно в этом нет ничего страшного. Такие идентификаторы, как _[A-Z_].*, зарезервированы для использования в будущем. Например, C99 представил _Bool, а C11 представил _Atomic и _Thread_local (среди многих других). Все они были названы так, потому что они вышли из «зарезервированного» пула, и любой, кто уже использовал эти ключевые слова / идентификаторы в своем собственном коде, нарушил правило. как правило не представляет риска для использования _StructName и т. д. Технически согласно стандарту, использование такого имени является неопределенным поведением, но я еще не сталкивался с ситуацией, когда это имело значение.

@Rerito fyi, стр. 166 из C99 черновик, Все идентификаторы, начинающиеся с символа подчеркивания и заглавной буквы или другого символа подчеркивания, всегда зарезервированы для любого использования. и Все идентификаторы, начинающиеся с подчеркивания, всегда зарезервированы для использования в качестве идентификаторов с областью видимости файлов как в обычном пространстве имен, так и в пространстве имен тегов.

Интересно, что в руководстве по кодированию ядра Linux говорится, что мы должны быть намного более консервативными в использовании typedefs (раздел 5): kernel.org/doc/Documentation/CodingStyle

@dreamlax "Вы не должны использовать идентификаторы с подчеркиванием, за которым следует заглавная буква". Речь идет о подчеркивании имен с, за которым следует верхний регистр, или подчеркивании начиная с, за которым следует верхний регистр? ring0 предполагает, что это второе, но после прочтения вашего комментария я подумал, что это первый.

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

@alternative: в некоторых реализациях лучше использовать структуру типа FILE; в других было бы лучше как союз. Если в конкретной реализации было бы лучше использовать объединение, то когда клиентский код везде будет указывать struct FILE *, реализация будет заключать объединение в бесполезную однокомпонентную структуру.

@alternative: Почему только "стандартная" библиотека? Я думаю, что многие виды библиотек могли бы лучше всего работать в одной реализации, имея union в качестве внешнего члена, а в других - имея struct. Лично я думаю, что было бы лучше, если бы вместо того, чтобы типы профсоюзов, C представили более детальный контроль над структурой макета (например, struct quad { unsigned long l; unsigned char b[4] @ l;}), в этом случае, то этот вопрос будет спорным [на самом деле, C все еще выиграет от этого], но это очевидно не то, что произошло.

@supercat, но важно, является ли непрозрачный объект структурой или объединением, вы должны сразу сказать. Если он непрозрачен, это не такая большая проблема, и все в стандартной библиотеке непрозрачно

@alternative: если тип имеет более одного непрозрачного поля, очевидно, важна ли это структура или объединение. Я не вижу причин, по которым стандарт C должен быть уникальным, имея непрозрачные или почти непрозрачные типы, которые не раскрывают более одного поля.

В вашем первом примере первая функция объявляет локальную переменную и возвращает эту переменную (точка a). Это вызовет предупреждение и является ошибкой. stackoverflow.com/questions/4824342/…

@Milhous Вовсе нет, я возвращаю значение, а не указатель.

@unwind Ах, вы правы. но использование значений в целом - очень плохая практика. Внутри метода он скопирует данные все. Например, это нормально, так как есть 8 байтов. Но представьте, если бы это было несколько мегабайт.

@Milhous На мой взгляд, это просто ошибочные рассуждения. А Point - это не несколько мегабайт. Возвращаемые значения превосходны с точки зрения семантики и удобочитаемости, а быть супер-ультра-гиперзащитным и думать: «О нет, некоторые программы манипулируют данными, которые слишком велики, чтобы их можно было вернуть, давайте возвращаем значения никогда» для меня не имеет смысла. Используйте правильный инструмент и т. д.

@unwind +1 Функции, возвращающие значение, также имеют то преимущество, что они могут быть помечены как __attribute __ ((const)) или чистые, и то и другое плохо работает с функциями, которые возвращаются через параметр указателя. К сожалению, простые компиляторы C плохо справляются с RVO (= вообще). Я однажды поигрался с этим, и g ++ имел на пару процентных пунктов более быстрый возврат по значению из-за копирования без RVO.

В первом фрагменте кода, не вводит ли в заблуждение возвращение структуры, размещенной в стеке?

Я не понимаю вашу часть В последнем случае вы не можете вернуть Point по значению, поскольку его объявление скрыто от пользователей файла заголовка., почему она связана с typedef?

Не могли бы вы рассказать мне, как здесь работает if ((p = malloc(sizeof *p)) != NULL), хотя это и не связано с вопросом? Заранее спасибо.

@AkshayImmanuelD Нет, поскольку структура обрабатывается как значение, она не отличается от возврата целого числа (сравните const int x = 17; return x;). Все значение копируется по значению, указатели не используются, поэтому место хранения оригинала не имеет значения.

@taritgoswami Что сбивает с толку? Выражение sizeof *p - это способ во время компиляции вычислить количество байтов, необходимых для хранения того, на что указывает p, и устраняет необходимость вручную вводить имя типа в дополнительное время.

Спасибо, а когда экспрессия (p = malloc(sizeof *p)) может быть NULL?

@taritgoswami Функция malloc() возвращает NULL, если ей не удается выделить запрошенный объем памяти. Это базовые знания C.

Повторный комментарий Уильяма Перселла повсюду означает, что структура используется в любое время

Противоположная точка зрения: использование typedef struct Xyz XYZ и последующее определение переменной как имеющей тип XYZ вместо struct Xyz повышает фактор путаницы, потому что XYZ выглядит как элементарный тип, когда это является на самом деле struct.

@ BobJarvis-ReinstateMonica: Еще одна причина в пользу ключевого слова struct: можно создавать и использовать указатели на неполные типы структур, идентифицированные с помощью ключевого слова struct и тега, без необходимости указания типа где-либо в модуле компиляции. Если кому-то может понадобиться использовать struct и имя тега, я думаю, что лучше последовательно указывать тип таким образом, чем иногда указывать его таким образом, а иногда использовать typedef.

Один из примеров того, когда имя тега совпадает с именем без тега, находится в программе (POSIX или Unix) с функцией int stat(const char *restrict path, struct stat *restrict buf). Здесь у вас есть функция stat в обычном пространстве имен и struct stat в пространстве имен тегов.

ваше заявление, S S; // ошибка .... НЕПРАВИЛЬНО Работает хорошо. Я имею в виду ваше утверждение, что "у нас не может быть одинакового имени для тега typedef и var" НЕПРАВИЛЬНО ... пожалуйста, проверьте

Хуже того, ваша опечатка может совпадать с другим тегом. В случае структуры это может привести к правильной компиляции всей программы и поведению undefined во время выполнения.

это определение: 'typedef {FIRST_ITEM, SECOND_ITEM} EnumDef;' не определяет перечисление. Я написал сотни огромных программ и имел несчастье выполнять обслуживание программ, написанных другими. Судя по опыту, использование typedef в структуре приводит только к проблемам. Будем надеяться, что программист не настолько ограничен, что у него возникнут проблемы с вводом полного определения при объявлении экземпляра структуры. C не является базовым, поэтому ввод еще нескольких символов не повредит работе программы.

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

Обратите внимание, что обычно не рекомендуется использовать enum в качестве типа, так как многие компиляторы выдают странные предупреждения при их использовании «неправильно». Например, инициализация enum значением 0 может дать предупреждение «целочисленная константа не входит в перечисление». Форвардное объявление enum также не допускается. Вместо этого следует использовать int (или unsigned int).

Этот пример не компилируется, и я бы этого не ожидал. Компиляция Debug / test.o test.c: 10: 17: ошибка: поле имеет неполный тип enum EnuumDef enum EnuumDef MyEnum; ^ test.c: 10: 8: примечание: прямое объявление перечисления EnuumDef enum EnuumDef MyEnum; ^ 1 ошибка. gnuc с std = c99.

В clang ang gcc с c99 этот пример не компилируется. Но вроде Visual Studio ни на что не жалуется. rextester.com/WDQ5821

@ M.M «Хуже того, ваша опечатка может совпадать с другим тегом. В случае структуры это может привести к правильной компиляции всей программы и неопределенному поведению во время выполнения». - Не могли бы вы привести пример? Что именно будет обозначать этот другой тег? Структурный тег? Но разве структурные теги не требуют наличия ключевого слова struct перед определением переменной этой структуры? В противном случае мы получили бы ошибку компилятора. Как это вызывает UB?

@cschol Я бы порекомендовал вам удалить этот ответ или значительно изменить его, потому что он просто неправильный (или, по крайней мере, больше не правильный). Ни на C, ни на C++ вы не получите скомпилированный код первого примера. Я тестировал его с помощью clang и gcc, здесь: godbolt.org/z/Moskd4, и даже с их более старыми версиями. Не только один раз это проходило без хотя бы одной ошибки.

Иметь самодостаточные структуры совсем несложно. struct foo {struct foo * следующий; int вещь; }

...какие? Сказать препроцессор для описания разрешения structs и typedefs достаточно плохо, но остальная часть вашего письма настолько сбивает с толку, что мне трудно получить от него какое-либо сообщение. Однако я могу сказать одну вещь: ваша идея о том, что не-typedefd struct нельзя объявлять вперед или использовать в качестве непрозрачного (указателя) члена, полностью ложна. В вашем 1-м примере struct b может тривиально содержать struct a *, typedef не требуется. Утверждения о том, что struct являются просто тупыми частями макрорасширения и что typedef наделяют их новыми революционными возможностями, до боли неверны.

Чисто было бы не повторять struct везде ... Typedef создает новые типы. Что ты используешь? Типы. Мы не используем забота, если это структура, объединение или перечисление, поэтому мы определяем его typedef.

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

@BerndJendrissek: Структуры и объединения отличаются от других типов, но должен ли клиентский код заботиться о том, какая из этих двух вещей (структура или объединение) является чем-то вроде FILE?

@supercat FILE - хорошее использование typedef. Я думаю, что typedef - это злоупотребляли, а не потому, что это ошибка языка. ИМХО, использование typedef для всего - это запах кода "спекулятивной сверхобобщенности". Обратите внимание, что вы объявляете переменные как FILE * foo, а не как FILE foo. Для меня это важно.

@BerndJendrissek: Если бы переменные, идентифицирующие файлы, имели тип FILE, а не FILE*, было бы неясно, когда / должны ли методы использовать параметры типа FILE по сравнению с FILE*. В Паскале обычным режимом использования было бы наличие переменных самого типа, но при этом методы принимали бы параметры этого типа по ссылке; C не имеет параметров по ссылке, хотя [я смутно припоминаю, что Паскаль не позволяет передавать переменные типа File или Text по значению, таким образом избегая какой-либо двусмысленности относительно того, что это должно означать].

@BerndJendrissek: Кстати, мне лично интересно, предлагают ли типы объединения какие-либо преимущества, будь то удобство для программистов или простота компилятора, по сравнению с наличием средств явного псевдонима элементов структуры? Я бы подумал, что механизм псевдонима будет проще реализовать для компилятора и более полезен для программистов, особенно если бы в него были включены битовые поля, например int mode_settings; unsigned mode @mode_settings.0:4; unsigned enable @mode_settings.31:1;. Я не знаю, используют ли в настоящее время какие-либо компиляторы @внутри структур таким образом, чтобы это противоречило этому, но ...

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

@supercat: «Если бы переменные, идентифицирующие файлы, имели тип FILE, а не FILE * ...» Но это именно та двусмысленность, которую допускают typedefs! Мы просто привыкли, что fopen берет ФАЙЛ *, поэтому мы не беспокоимся об этом, но каждый раз, когда вы добавляете typedef, вы вводите еще одну часть когнитивных издержек: нужен ли этому API foo_t args или foo_t *? Явное выполнение «структуры» улучшает локальность рассуждений, хотя и за счет нескольких дополнительных символов на определение функции.

@BerndJendrissek: Проблема с переносом нотации struct заключается в том, что во многих случаях реализация должна иметь возможность использовать union, а не struct, без необходимости заботы клиентского кода. Если бы C не включил типы union, но вместо этого включил средства явного псевдонима полей структуры, то это не было бы проблемой, но поскольку это типы struct и union, различны. Клиентский API должен заботиться о том, чтобы FILE не определялся типом как массив (они ведут себя странно), но в остальном не должно заботиться о том, что это такое.

@supercat Это интересный момент, и я согласен, только теоретически вы можете обернуть объединение внутри структуры, верно? (Структура с одним членом объединения) И, таким образом, вы не измените публичный интерфейс своей новой реализации.

@DavidCallanan: С момента написания вышеизложенного я перешел к использованию синтаксиса struct tag и больше не использую структуры typedef. Решающим фактором был тот факт, что если у кого-то есть заголовок widget.h с функцией int importWidgetFromWazzle(struct widget *dest, struct wazzle *src);, но не все клиенты используют wazzles, использование синтаксиса структурных тегов позволит избежать необходимости включать код клиента wazzle.h, размещать wazzle.h там, где widget.h может его найти. , или займитесь другой гимнастикой. Если бы в C было указано всегда, typedef struct foo foo; будет проигнорирован, если foo уже определен ...

... таким образом библиотека Wazzle могла бы указать, что клиенты могут на досуге содержать typedef struct wazzle wazzle. Я думаю, что полезность этого подсказала мне автономная реализация, которая включает реализацию fprintf и содержит typedef struct __FILE FILE;, но не включает никаких определений для fwrite или типа структуры. Таким образом, пользовательский код может определить struct __FILE, чтобы он содержал все элементы, которые потребуются его реализации fwrite. Если бы в стандарте stdio.h использовался тип struct FILE* вместо FILE, ...

... это обеспечило бы естественный способ для автономных реализаций, позволяющий пользовательскому коду определять свой собственный тип файла, который мог бы работать с fprintf, без необходимости использовать зарезервированный идентификатор для тега файла, создавая потенциальную несовместимость между реализациями, которые выбирают структурный тег __FILE и те, которые случайно выбирают другой структурный тег (например, _FILE).

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

Питер ван дер Линден также выдвигает аргументы против определения типов структур в своей поучительной книге «Экспертное программирование на языке Си - секреты глубинного языка Си». Суть такова: вы ХОТИТЕ знать, что что-то является структурой или объединением, а не СКРЫТЬ это.

Стиль кодирования ядра Linux явно запрещает структуры с определением типов. Глава 5: Typedefs: «Это ошибка для использования typedef для структур и указателей». kernel.org/doc/Documentation/CodingStyle

Какие именно преимущества дает многократный ввод слова "struct"? И, говоря о загрязнении, зачем вам иметь структуру и функцию / переменную / typedef с одинаковыми именами в глобальном пространстве имен (если только это не typedef для той же функции)? Безопасный шаблон - использовать typedef struct X { ... } X. Таким образом, вы можете использовать короткую форму X для адресации структуры везде, где доступно определение, но все же можете пересылать объявление и использовать struct X, когда это необходимо.

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

В чем должна быть проблема с foo.h в этом примере? Вы все еще можете получить доступ к FOO_DEF, если вы перешли на typedef struct { struct bar *bar; } foo;

@MattMcNabb Я тоже этого не понимаю, ты разобрался?

@JanusTroelsen Да, теперь я понимаю: он должен отличаться от struct foo { Bar *bar; };, который требует, чтобы foo.h включал bar.h.

эта строка: '; typedef struct Point Point;' ясно делает мою «точку» о том, чтобы не определять тип структуры. Первая точка - это имя тега структуры. Вторая «Точка» - это «новый» тип. Теперь вам, компилятору и всем, кто читает код, необходимо отслеживать, какая «точка» имеется в виду.

@ user3629249 это не должно быть слишком сложно. Первому всегда будет предшествовать ключевое слово struct.

«Какие именно преимущества дает многократный ввод« struct »?» --- Сохраняет пальцы здоровыми благодаря большому количеству упражнений.

Извините, я добавил -1 :(, так как typedef-ing не предотвращает ничего хорошего, о чем вы упомянули, например, в заголовке opaque.h: typedef struct Opaque Opaque; extern Opaque *OpConstructor (void); extern void OpDestructor (Opaque *);, затем в opaque.c: struct Opaque { actual definition };

Ах да, очень читаемый struct foo *foo;. Иногда я задаюсь вопросом о C-кодерах.

@LorinczyZsigmond: если два заголовка содержат typedef struct Opaque Opaque;, код, который включает оба, будет несовместим со старыми компиляторами, которые доказали свою надежность, если заголовки не координируют использование макроса #define (что может способствовать еще большему загрязнению пространства имен), чтобы избежать дублирования определения .

@CivFan: если функция использует по одному объекту, каждый из более чем одного типа структуры, и их использование не соответствует никакому четкому шаблону, например «источник» и «место назначения», какие имена вы бы предпочли бы вместо этого? Конечно, можно было бы использовать что-то вроде struct foo *theFoo;, но действительно ли это проясняет что-то более ясное, чем было бы иначе? Идентификатор, который выходит из препроцессора, которому предшествует зарезервированное слово struct, не может быть ничем иным, кроме тега структуры, поэтому я не вижу оснований для путаницы.

@supercat очень верно, этот typedef принадлежит к opaque.h, который должен использовать включить охранников.. Другие заголовки должны либо включать opaque.h, либо использовать формат struct Opaque.

@LorinczyZsigmond: Если некоторые потребители woozle.h будут использовать функцию, которая принимает struct Opaque*, а некоторые нет, те, которые не используют эту функцию, не должно быть opaque.h где-нибудь в своем проекте. Кроме того, если opaque.h включает функцию, которая принимает struct woozle*, попытка обработки определений типов в каждом заголовке до того, как прототипы в другом, потребует координации имен защитных макросов между авторами двух библиотек, при этом просто используя типы struct opaque* и struct woozle* в прототипы избавят от необходимости иметь предварительные определения.

@supercat Я бы посоветовал struct Foo *foo, но да, ваш пример тоже подойдет и будет намного понятнее, чем struct foo *foo.

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

«Непрозрачность и« вспомогательные функции »сами по себе плохи». Может кто-нибудь объяснить почему? Я думаю, что сокрытие и инкапсуляция информации было бы очень хорошей идеей.

@Yawar Я только что прочитал этот документ и подумал точно так же. Конечно, C не объектно-ориентированный, но абстракция все еще актуальна.

@Yawar: Думаю, дело было «в самих себе». Предположим, у кого-то есть тип, который должен представлять трехмерную точку с использованием координат float. Можно потребовать, чтобы код, который хочет прочитать значение x точки, использовал для этого функцию доступа, и бывают случаи, когда действительно абстрактный тип «читаемой трехмерной точки» может быть полезен, но есть много других случаев, когда это необходимо это тип, который может делать все, что может делать тройка float x,y,z, с той же семантикой. В последних ситуациях попытка сделать шрифт непрозрачным приведет к путанице, а не к ясности.

@JonathonReinhart Было бы наглядно упомянуть, как этого можно избежать, например, как очень довольный GTK + работает вокруг этого: bugzilla.gnome.org/show_bug.cgi?id=140722 / mail.gnome.org/archives/gtk-devel-list/2004-April/msg00196.h‌ tml

«typedef вводит псевдоним для типа и находит его в пространстве имен тегов. А именно« typedef struct Tag{ ...members... }Type; »определяет две вещи» не совсем имеет смысла. если typedef определяет теги, тогда «Тип» здесь также должен быть тегом. По правде говоря, определение определяет 2 тега и 1 тип (или 2 типа и 1 тег. Не уверен): struct Tag, Tag и Type. struct Tag определенно тип. Tag - это тег. но путаница в том, является ли Type тегом или типом

Если бы в стандарте C всегда разрешалось повторение определений имен типов в тех случаях, когда старые и новые определения точно совпадают, я бы предпочел, чтобы код, который будет использовать тип структуры, включал typedef struct name name; как обычную практику, но из старых компиляторов которые зарекомендовали себя надежными, не допускают таких повторяющихся определений, и обход этого ограничения создает больше проблем, чем простое использование struct tagName в качестве имени типа.

"Оказывается, в C99 требуется typedef". Что ты имеешь в виду?

Речь идет о C, а не о C++. В C typedef является «обязательным» (и, скорее всего, всегда будет). «Обязательно», как в, вы не сможете объявить переменную Point varName; и сделать так, чтобы тип был синонимом struct Point; без typedef struct Point Point;.

typedef point { ... } Points - не самая лучшая идея. Поскольку названия point и Points имеют слишком большую разницу. Когда кому-то нужно переслать объявление struct для указателя, тогда другое имя становится проблемой, особенно когда оно находится в библиотеке, которая может измениться. Если вы используете typedef, используйте то же имя или четкое правило, как преобразовать имя из имени struct в имя typedef.