Могут ли библиотеки C ++, скомпилированные с помощью VC10 (sp1), быть связаны кодом, скомпилированным с помощью VC11? - PullRequest
4 голосов
/ 03 апреля 2012

Вопрос говорит сам за себя.

Я понимаю, что VC11 в настоящее время находится только в бета-версии, но я спрашиваю:

  1. опыт попыток установить связь с закрытымИсходная (широко используемая, если возможно) библиотека, скомпилированная со спецификациями vc10
  2. от Microsoft, которая явно говорит, что если да или нет, vc11 сможет связываться с библиотеками vc10.

Я говорютолько в случае C ++.

Ответы [ 4 ]

3 голосов
/ 03 апреля 2012

Вы можете прочитать этот ответ для случая динамическое связывание .

Что касается статического связывания , я думаю, что вы не можете безопасно связывать библиотеки C ++, написанные с помощью VCx, с кодом, скомпилированным с помощью VCy. Например, реализации контейнеров STL меняются от версии к версии (и даже в одной и той же версии есть изменения между режимом отладки и выпуска, а также такими настройками, как _HAS_ITERATOR_DEBUGGING и т. Д.).

Цитирование сопровождающего VC ++ STL :

STL никогда не имеет и никогда не гарантирует бинарную совместимость между разными основными версиями. Мы применяем это с помощью компоновщика ошибки при смешивании объектных файлов / статических библиотек, скомпилированных с различные основные версии, которые оба VC10 + [...]

1 голос
/ 03 апреля 2012

Это громкое нет!В каждом крупном выпуске VS есть новая версия динамического CRT, имена для которого - msvcr90.dll для VS2008, msvcr100.dll для VS2010, msvcr110.dll для VS11.

Использование динамического CRT (опция компиляции / MD)важно, когда вы возвращаете объекты C ++, такие как std :: string из экспортируемой функции, или возвращаете любой указатель, который должен быть удален клиентским кодом.Это может работать правильно только тогда, когда клиентский код использует ту же версию CRT, что и DLL.Неявным является то, что это не будет иметь место, когда каждый из этих фрагментов кода будет иметь свою собственную зависимость от версии msvcrXXX.dll, у них неизбежно будут несовместимые версии CRT, которые не используют один и тот же распределитель кучи.

Вы можете написать DLL-файлы, которые можно безопасно использовать с любой версией CRT, но для этого необходимо тщательно разработать API, чтобы эти зависимости не существовали.Модель COM Automation является примером этого.

1 голос
/ 03 апреля 2012

Для динамических библиотек проблем не должно быть, поскольку они следуют четко определенным ABI. Вы можете в любое время ссылаться на dll из любого компилятора.

Статические библиотеки сложнее. Насколько я знаю, Microsoft никогда не гарантировала кросс-компиляторную совместимость для них. В частности, такие функции, как генерация кода во время компоновки, как известно, нарушают совместимость между более ранними выпусками. Файлы .lib не имеют единого четко определенного формата, как это делают библиотеки DLL.

Это может сработать, потому что Microsoft редко нарушает совместимость без необходимости, но, насколько мне известно, это не гарантируется.

Конечно, если фактические функции и типы, предоставляемые DLL, не совпадают, вы столкнетесь с проблемами.

В VC11 размеры почти всех структур данных стандартной библиотеки были изменены (Microsoft наконец использует пустую оптимизацию базового класса, эффективно уменьшая размер всех контейнеров, которые используют распределитель по умолчанию.), Поэтому попытка передать std::string из DLL, скомпилированной с помощью VC10, в модуль, скомпилированный с помощью VC11, непременно сломается.

0 голосов
/ 03 апреля 2012

Я не вижу причин, по которым они могут быть несовместимыми. Независимо от того, какой компилятор C ++ вы использовали для создания файлов LIB, как только они следуют спецификации формата. Вы можете проверить этот вопрос , если вы заинтересованы в деталях формата.

...