Если структура определена с использованием определения struct {...}
, маловероятно, что в исполняемом коде будет какая-либо информация, связанная с именами элементов. Некоторые платформы встраивают «отладочную» информацию в сгенерированные исполняемые файлы, и могут быть какие-то средства, с помощью которых работающая программа может получить эту информацию, но нет общего способа сделать такие вещи.
Однако можно уметь использовать макросы для определения структуры. Например, можно определить:
#define MAKE_ACME_STRUCT \
FIELD(id,int,23) \
X FIELD(name,char30,"Untitled") \
X FIELD(info,int,19) \
// LEAVE THIS COMMENT HERE
, а затем вызывать макрос MAKE_ACME_STRUCT несколько раз, причем макросы FIELD и X определены различными способами, так что он будет расширяться либо до оператора структуры, либо из выражения инициализации для экземпляра этой структуры по умолчанию или как выражение инициализации для массива элементов, описывающих поля структуры [например, что-то вроде
STRUCT_INFO acme_struct_info[] = {
{"id", STRUCT_INFO_TYPE_int, sizeof(ACME_STRUCT.id), offsetof(ACME_STRUCT.id)}
,{"name", STRUCT_INFO_TYPE_char30, sizeof(ACME_STRUCT.name), offsetof(ACME_STRUCT.name)}
,{"info", STRUCT_INFO_TYPE_int, sizeof(ACME_STRUCT.info), offsetof(ACME_STRUCT.info)}
,{0}};
Было бы необходимо, чтобы все типы, используемые в структуре, имели имена с одним токеном и чтобы для каждого такого имени был определен идентификатор STRUCT_INFO_TYPE_nameGoesHere
, который идентифицирует тип для библиотеки времени выполнения в некоторой форме, которую он понимает. .
Такие макросы вряд ли прекрасны, но они имеют преимущество в том, что все вещи, которые они используют для определения, остаются синхронизированными [например, гарантируя, что добавление или удаление элемента acme_struct
приведет к его добавлению или удалению из списка членов структуры, хранящегося в acme_struct_info
].