Можно ли связать разные диалоги GCC?

Я знаю, что в принципе это, вероятно, поведение undefined, но в интересах решения большого проекта, здесь мой вопрос о GCC:

Предположим, что я скомпилировал один блок трансакций с gcc -std=c++98, а другой с -std=c++11, используя ту же самую установку компилятора. Есть ли какая-то гарантия того, что я могу связать два объектных файла и получить четко определенную программу?

Насколько я могу судить, потенциальные проблемы могут возникать только из разных представлений заголовков библиотек из-за различий в макросах, а те, в свою очередь, в лучшем случае добавят новые функции-члены, но никогда не будут объектами-членами, в стандартные классы библиотек.

Может ли это сделать приемлемым для компиляции различных частей более крупного проекта с различными языковыми диалектами?

Обновление: Я должен добавить ортогональный вопрос: как насчет использования двух разных версий GCC (скажем, 4.3 и 4.6), но с тем же параметром диалекта (-std=c++98)? Список в этой документации GCC, кажется, предполагает, что библиотека совместима в обоих направлениях между 4.2.2 и 4.6.

Ответы

Ответ 1

A priori, no. Самое безопасное решение - предположить, что все параметры компилятора идентичны, за исключением случаев, когда компилятор специально документирует, что этот параметр не влияет на двоичную совместимость. (Документация, которой в большинстве компиляторов не хватает). На практике, при отсутствии документации, кажется, что безопасные ставки, что опции, которые управляют предупреждениями (-W... в g++), не будут влиять на двоичную совместимость и что параметры, которые влияют на код (уровень языка и т.д.): g++ обычно поддерживает совместимость на разных уровнях оптимизации, где, как VС++, нет.

Другой реальной проблемой является определение символов препроцессора в командной строке. Опять же, самая безопасная ставка заключается в том, что все определения должны быть идентичными, но опять же, некоторый здравый смысл в порядке: вряд ли можно ожидать, что стандартная библиотека будет скомпилирована с символами препроцессора, которые используются в вашем проекте (например, MYPROG_CONFIG_FILE_LOCATION, скажем). С другой стороны, имейте в виду, что определения препроцессора _GLIBCXX_DEBUG и _GLIBCXX_DEBUG_PEDANTIC будут влиять на двоичную совместимость (хотя g++ гарантирует, что вы получите версию библиотеки, которая работает с ними, если вы будете использовать их последовательно).

Что касается вашего вопроса: я бы не ожидал значительного влияния на двоичную совместимость из-за стандартной версии, но вряд ли это меня удивит, если выбор повлияет на некоторые предопределенные символы препроцессора таким образом, чтобы нарушить двоичную совместимость в в библиотеке, как если бы вы скомпилировали некоторые из модулей с _GLIBCXX_DEBUG, а некоторые - без. Это может сработать, но я не буду рассчитывать на это.