C, C++, грабли

[beldmit]

Наступил на грабли. gcc и g++ дают разный размер довольно развесистой структуры, используемой в сишной и плюсовой библиотеках.

Можно ли малой кровью их привести к единому знаменателю? С-шная библиотека не наша, плюсовая наша.

Вроде бы везде стоят флаги
#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */

Опцию -fpack-struct пробовал, не преуспел.

Update: разные опции сборки базовой и производной библиотек.

Comments

[malobukov]

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

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

[vladimir000]

Именно так. Теоретически что-то можно придумать, но жить это будет - самый максимум до перекомпиляции на омпьютере с другой архитектурой или размером данных.

[nasse]

Хм. Тест.

[beldmit]

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

[elglin]

Я уже давно не сварщик, но придумывается только восход солнца руками в духе:

char pseudostruct[16]; /* int, char[4], double */

int get_a(char* p){ return *((int*)p); }
void set_a(char* p, int v){ *((int*)p) = v; }
char* get_b(char* p){ return p + 4; }
void set_b(char* p, char* v){ strncpy(p, v, 4); }
double get_c(char* p){ return *((double*)(p + 8)); }
void set_c(char* p, double v){ *((double*)(p + 8)) = v; }

Обвешать inline по вкусу. Но это уже подозрительно напоминает попытку ASM-вставки без ASM-вставки и той самой ручной оптимизации, которая очень эффективно замедляет код.

[beldmit]

Да, я это тоже придумал как один из вариантов.

[being_no_one]

Опасный фокус даже в этом примере. Если бы размер int был 8 байт, то аналогично реализованный get_c содержал бы UB, ибо *((double*)(p + 12)) нарушает требования к выравниванию для double; при попытке поступить так с действительно большой структурой шанс наступания на эти грабли опасно высок.

[elglin]

Без фигни опасный, а еще int разный на разных архитектурах. Тут для стабильности надо структуру делать кратной 64 битам (то есть не char[], а int64_t[]), молиться, что этот кусок кода выкинут до перехода на 128-битовое слово, и все равно при такой указательной магии есть шанс отстрелить себе ногу.
Мой научник 20 лет назад поминал идею о том, что иногда стоит сделать конский malloc(), а дальше внутри него раскладывать то, что тебе нужно, по сути, реализуя свой маленький менеджер памяти. Это вот ровно то же самое; подозреваю, это до сих пор верно в ситуациях, когда у тебя 64К памяти, и ты реально лучше любого компилятора знаешь, что где как должно лежать.

[vitus_wagner]

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

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

Потому что в системных ABI разных операционных систем ДО ХРЕНА структур, передаваемых как параметры и как-то это работает.