размер указателя не будет меняться; это зависит от разрядности платформы и модуля, а не от компилятора (32-разрядный или 64-разрядный и т. д.).
Что может варьироваться, так это размер в основном всего остального, а будет отличаться от шаблонов.
Заполнение и выравнивание структур, как правило, зависит от компилятора и часто зависит от настроек внутри компилятора. Существуют настолько свободные правила, как указатели, как правило, находящиеся на границе платформности и bool, имеющие 3 байта после них, но компилятору решать, как с этим справиться.
Шаблоны, особенно из STL (который отличается для каждого компилятора), могут иметь разные члены, размеры, отступы и, в основном, все что угодно. Единственная стандартная часть - это API, бэкэнд оставлен для реализации STL (есть некоторые правила, но компиляторы могут по-разному компилировать шаблоны). Передача шаблонов между модулями из одной сборки достаточно плоха, но между разными компиляторами это часто может быть фатальным.
Вещи, которые не стандартизированы (искажение имени) или весьма специфичны по необходимости (распределение памяти), также будут несовместимы. Обе эти проблемы можно обойти, только удалив из создавшей библиотеки (во всяком случае, хорошая практика) и используя объекты STL, для которых требуется средство удаления, для выделения и экспорта с использованием недекорированных имен и / или стиля C (extern "C"
) для экспортируемые методы.
Мне также кажется, что я помню одну хитрость в том, как компиляторы обрабатывают виртуальные деструкторы в vtable, с небольшой разницей.
Если вам удастся передать только ссылки на ваши собственные объекты, полностью избежать внешне видимых шаблонов, работать в основном с указателями и экспортированными или виртуальными методами, вы можете избежать подавляющего большинства проблем (COM делает именно это, для совместимости с большинство компиляторов и языков). Писать может быть больно, но если вам нужна такая совместимость, это возможно.
Чтобы устранить некоторые, но не все проблемы, использование альтернативы STL (например, базовой библиотеки Qt) устранит эту конкретную проблему. Бросить Qt в любой старый проект - отвратительная трата и вызовет больше раздувания, чем «повысить ВСЕ ВЕЩИ !!!» философия, это может быть полезно для разъединения библиотеки и компилятора в большей степени, чем использование стандартного STL.