в C (ANSI, C99 та ін.) структури живуть у власному просторі імен. Структура для пов'язаного списку може виглядати приблизно так:
struct my_buffer_type {
struct my_buffer_type * next;
struct my_buffer_type * prev;
void * data;
};
Однак, здається, цілком природно, що для більшості програмістів на C автоматично вводити такі структури, як нижче
typedef struct tag_buffer_type {
struct tag_buffer_type * next;
struct tag_buffer_type * prev;
void * data;
} my_buffer_type;
А потім посилайтесь на структуру як на звичайний тип, тобто get_next_element(my_buffer_type * ptr)
.
Тепер моє запитання: чи є конкретна причина цього?
У Вікіпедії йдеться про http://en.wikipedia.org/wiki/Typedef#Usage_concerns
Деякі люди проти широкого використання typedefs. Більшість аргументів зосереджені на ідеї, що typedefs просто приховує фактичний тип даних змінної. Наприклад, Грег Кроа-Хартман, хакер ядра Linux та документатор, відмовляє їх у використанні для будь-якого, крім декларацій прототипу функцій. Він стверджує, що така практика не тільки необгрунтовано обтяжує код, але також може спричинити програмістів випадково неправомірного використання великих структур, вважаючи їх простими типами. [4]
Інші стверджують, що використання typedefs може полегшити підтримку коду. K&R заявляє, що існують дві причини використання typedef. По-перше, він забезпечує засіб зробити програму більш портативною. Замість того, щоб змінювати тип скрізь, де він відображається у всіх вихідних файлах програми, потрібно змінити лише одну заяву typedef. По-друге, typedef може полегшити розуміння складної заяви.
Мені особисто цікаво, чи не існує достатньої користі від того, щоб мати окремий struct
простір імен, щоб іноді не використовувати структури typedef'd, і оскільки існує декілька культур програмування С (навколо мого досвіду програмування Windows C має інші традиції, ніж програмування Linux C) традиції, які я не знаю.
Тоді мене цікавлять історичні міркування (попередники, перші версії С).
typedef
- приховати фактичний тип змінної. Візьмемоtime_t
для прикладу: якщо люди перейдуть, використовуючи основний цілий тип, зміна в реалізації такої, яка буде потрібна в 2038 році, порушить дуже багато коду. FЯкщо люди використовують структури, не розуміючи, чому, це невдача програміста, а не конструкції.