Предположим, что существует спецификация интерфейса «X». X призывает к XHeader.h иметь структуру под названием X_Fiddle, которая гарантирует наличие элементов foo и bar, оба типа int. Однако члены, определяющие реализацию, не запрещены и на самом деле поощряются, если это повышает эффективность. Мне нужно написать реализацию X для компании я работаю, и понял, что наличие нескольких членов, специфичных для моей реализации, чтобы сохранить какое-то состояние было бы очень удобно, так что я написал следующее:Выделение типов и переменных, специфичных для реализации, в C
typedef struct X_Fiddle {
int foo; /* Guaranteed by spec */
int bar; /* Guaranteed by spec */
size_t dinky_dingbat; /* IMPLEMENTATION-SPECIFIC, DO NOT USE */
unsigned char *dingbat_data; /* IMPLEMENTATION-SPECIFIC, DO NOT USE */
} X_Fiddle;
Конечно , пользователям нечего сообщать, что dinky_dingbat или dingbat_data не должны использоваться, так как они являются специфичными для реализации деталями и могут измениться или исчезнуть в какой-то момент в будущем. Учитывая, что я не могу скрыть реализацию, используя что-то вроде непрозрачных указателей, что делать, чтобы выделять такие внутренние элементы (или другие трюки, чтобы скрыть такие вещи)? Существуют ли обычно используемые/стандартные способы решения таких проблем? Лучшее, что я мог подумать, - это использовать соглашение об именах, например, подчеркивание подчеркивания, но я не уверен, применимы ли правила подчеркивания к переменным-членам, и я чувствую, что меня тоже смешивают с некоторыми специальными правилами на С ++. Я также подумал о том, чтобы называть их чем-то вроде INTERNAL_dinky_dingbat или иметь отдельную структуру для внутренних типов, содержащуюся внутри X_Fiddle, но я хотел бы сохранить дополнительную типизацию до минимума, чтобы мне было немного не нравиться. Или это вполне приемлемо только для того, чтобы иметь простую, обычную структуру, как указано выше, где детали, специфичные для реализации, изложены в комментариях и документации, оставляя менее опытных и прилежных, чтобы они страдали от своих самоназванных ран, когда мне нужно изменить ситуацию ?
Предполагая, что я начинаю с нуля и/или моя компания/команда не имеет соглашения для этого конкретного случая.
Я думаю, что вы слишком беспокоитесь о том, что пользователи обращаются к закрытым членам. Либо используйте непрозрачные указатели на структуру с функциями доступа, либо просто оставляйте определения структуры на своем месте, прокомментируйте каждый элемент как '/ * public * /' или '/ * private * /' и напишите документацию. –