Статическое связывание с библиотекой, созданной с использованием другой версии библиотеки времени выполнения C, хорошо или плохо?

Question

Рассмотрим этот сценарий:Приложение ссылается на стороннюю библиотеку A.

A создан с использованием MSVC 2008 и статически связывается (т.построенный с помощью /MT) в библиотеку времени выполнения C v9.0.

Приложение создано с использованием MSVC 2005 и статически связывается с A и (с использованием /MT) с библиотекой времени выполнения C v8.0.

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

Уделяется ли внимание обеспечению совместимости заголовков библиотеки времени выполнения между версиями, или следует всегда следить за тем, чтобы все статически связанные библиотеки ссылались на одну и ту же версию библиотеки времени выполнения?

Answer 1

Это должен не быть проблемой.Каждая библиотека связана со своей собственной средой выполнения и в основном функционирует независимо от других библиотек в этом процессе.Проблема возникает, когда библиотеки ABI плохо определены.Если какой-либо объект, выделенный в куче, выделяется в одной библиотеке, передается через границу библиотеки и «освобождается» в другой библиотеке, возникнут проблемы, поскольку для освобождения блока из диспетчера кучи, используемого для выделения, используется другой менеджер кучи. это.

Любой вид структуры, объекта или объекта, определенного во время выполнения C, не должен передаваться через границы, где может использоваться другая версия времени выполнения: - FILE*, полученный, например, из одной библиотеки, не будет иметь никакого значения для другой библиотеки, связанной с разное время выполнения.

Пока API библиотеки использует только необработанные типы и не пытается free() передать указатели или передать указатели на внутреннюю память malloc(), которую, как они ожидают, приложение (или другая библиотека) освободит(), вы должно быть хорошо.

Легко поддаться заблуждению, что «все может пойти не так», если смешаны среды выполнения C, но вы должны помнить, что библиотеки и динамические библиотеки (.so / .dll / .dylib) традиционно разрабатывались в широком разнообразии. языков:позволяя коду, написанному на asm, c, c++, fortran, pascal и т. д., взаимодействовать через эффективный двоичный интерфейс, эффективный для процессора.

Зачем вдруг паниковать, когда C связывается с C?

Answer 2

Это очень плохой план.Избегать.Либо перекомпилируйте библиотеку в 2005 году, либо скомпилируйте приложение в 2008 году.

Answer 3

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