Совместимость библиотеки ABI между версиями Visual Studio

У меня есть два сценария. Предположим, у меня есть 3 разделяемые библиотеки, которые экспортируют символы C ++, каждая из которых построена на VS7.1, VS8 и VS9. Я компилирую все 3 в VS9. Почему-то это работает. Мне не нужно перекомпилировать первые 2 библиотеки в VS9 для компоновщика VS9, чтобы успешно найти символы и связать их.

Теперь, если у меня есть библиотека, которая экспортирует только символы с использованием синтаксиса C (extern «C»), это то же самое? Я слышал, как люди говорят, что ABI для C стандартизирован, поэтому есть некоторая гарантия, что вы можете использовать библиотеку C, скомпилированную в Visual Studio 8, во всех версиях Visual Studio.

По сути, сочетание всего этого сбивает с толку. Я не уверен, какие у меня есть гарантии при связывании совместно используемых библиотек как на C ++, так и на C (с использованием соответствующих им библиотек импорта) между разными версиями Visual Studio. Я хотел бы услышать общий консенсус в отношении прямой и обратной совместимости как C И импорта C ++, так и статических библиотек в любой другой версии Visual Studio.

Причина, по которой это возникло для меня, заключается в том, что я использую библиотеки с закрытым исходным кодом, которые были скомпилированы в Visual Studio .NET 2003 (VS7.1). Моя команда думает, что это ограничивает нас компилятором VS 7.1, однако я пошел и протестировал эти библиотеки как в VS8, так и в VS9, даже в VS2010, и они прекрасно связываются. Однако я не уверен в том, что в этом заложена опасность. Обратите внимание, что рассматриваемая библиотека имеет вариант C и вариант C ++. По сути, вариант C - это стандартный экспорт C, а библиотека C ++ представляет собой абстракцию над библиотекой C и экспортирует классы.


person void.pointer    schedule 10.02.2012    source источник
comment
Тот факт, что вы можете использовать двоичный файл, скомпилированный в предыдущей версии Visual Studio, в более поздней версии, является отчасти совпадением. Это не гарантируется, и вы не должны на это полагаться. Это действительно должно заблокировать вас в более старой версии компилятора, если вы не можете получить версию двоичного файла, которую вы можете связать динамически (т.е. DLL). Если вы действительно решите использовать новую версию компилятора, всестороннее тестирование совершенно неизбежно.   -  person Cody Gray    schedule 13.02.2012
comment
@CodyGray: Я согласен, что это совпадение, но поскольку эти компиляторы уже выпущены и являются такими, какие они есть, у меня есть гарантия, что они будут работать. Я думаю, что у меня нет гарантии, что это будущие версии компилятора VS.   -  person void.pointer    schedule 13.02.2012
comment
Что ж, вроде как правда. У вас есть гарантия, что все, что вы тщательно тестируете и проверяете на работу, всегда будет работать. У вас нет гарантии (по крайней мере, не предусмотренной в документации), что любой код будет работать. Отсюда необходимость тестирования. Согласны, хотя вы, вероятно, можете обойтись без него для старых версий, и сразу же о том, что будущие выпуски будут подбрасыванием.   -  person Cody Gray    schedule 14.02.2012


Ответы (2)


Проблема может заключаться не только в различиях ABI (соглашениях о вызовах и т. Д.) Между этими версиями VS, но и в удаленных / измененных символах в системных библиотеках DLL. См. эту таблицу для подробного сравнения системной DLL. библиотеки между VS8 (2005, Windows SDK 5.0) и VS9 (2008, Windows SDK 6.0).

См. Также матрицу совместимости для Windows SDK.

введите описание изображения здесь

person linuxbuild    schedule 13.02.2012
comment
Я не понимаю, какое значение имеют здесь изменения Windows SDK, поскольку двоичный файл с закрытым исходным кодом, созданный с использованием MSVC 7.1, всегда будет загружать среды выполнения MSVC 7.1, с которыми он был создан. - person void.pointer; 15.05.2012

extern "C" экспортированные символы отличаются от символов C ++. В C ++ есть искажение имен (см. http://en.wikipedia.org/wiki/Name_mangling).

Изменение символов C ++ может варьироваться от версии компилятора к версии компилятора, поэтому в вашей настройке VS7 / 8/9 одно и то же имя метода C ++ может быть изменено на разные имена.

По сути, ваша команда кажется права - вы будете заблокированы в той же основной версии компилятора, которая использовалась для компиляции вашей библиотеки.

person Jörg Beyer    schedule 10.02.2012
comment
Как же тогда я могу использовать библиотеки C ++ VS7.1 и VS8 в VS9? - person void.pointer; 11.02.2012
comment
Согласно вашей ссылке в Википедии, VS6-VS10 используют одноименную схему искажения, которая объясняет, почему они работают. Так что на самом деле, кажется, безопасно обмениваться библиотеками C ++ между этими компиляторами. - person void.pointer; 11.02.2012
comment
@RobertDailey: Некоторые библиотеки C ++, но ничего, связанного со стандартной библиотекой (реализации меняются между версиями компилятора, что нарушает ODR). Безопаснее всего придерживаться чистого экспорта C между версиями компилятора. - person ildjarn; 11.02.2012