Является ли время смешивания жизнеспособным решением?

Question

В моей компании мы недавно перешли с VC9 на VC10.

Мы перенесли наши проекты, но затем ответственный сотрудник сказал нам, что нам придется хранить некоторые базовые общие DLL, скомпилированные с VC9, на наших производственных машинах.в течение некоторого времени.

Эти библиотеки DLL используют пользовательские структуры, некоторые из которых содержат std::vector, std::map и так далее.Теперь до меня дошло, что размер стандартных контейнеров изменился: некоторые стали больше, некоторые стали меньше.В результате размер наших пользовательских структур также изменился.

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

Лично я считаю, что это «решение» ужасно, потому что, хотя размер имеет значение, так жемакет конструкций.Для меня увеличение объема памяти всех структур для решения организационных проблем кажется действительно неправильным.

Если коротко, мой вопрос: возможно ли даже использовать одновременно два разных времени выполнения (используя описанный трюк или любой другой?).Другой трюк) при использовании не-C типов в прототипах функций?Есть ли у вас хороший / плохой опыт в отношении аналогичной ситуации?

Answer 1

STL никогда не имеет бинарной совместимости между различными основными версиями. Таким образом, если у вас есть DLL с классами STL на интерфейсе, вы должны использовать тот же компилятор и тот же вариант CRT для клиента DLL и самой DLL.

Если вы хотите создавать библиотеки DLL, которые можно безопасно использовать с различными версиями компилятора, у вас есть несколько вариантов, например:

1. Предоставление интерфейса pure C (DLL может быть написана на C ++, но интерфейс должен быть чисто C, а исключения C ++ не могут пересекать границы DLL).
2. Предоставление абстрактных интерфейсов на интерфейсе DLL, как описано в этой статье .
3. Использование COM .

Answer 2

Я уже делал это раньше, добавляя структуры аналогичным образом.Да, вы можете использовать две разные среды выполнения, и они должны нормально работать, если ABI одинаковы: вот где вы можете удариться о стену, когда структуры начнут изменять размеры, и переместить C ++ (где ABI повсюду) поверхГраницы DLL очень, очень грязные.Особенно учитывая, что VC10 имеет довольно много изменений в ожидании C ++ 11.Я использую C в тех случаях, когда речь идет о DLL, исключительно для тех гарантий, которые он дает мне в плане бинарной совместимости.

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

Answer 3

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

Из вашего вопроса у меня сложилось впечатление, что вы будете ссылаться на некоторые библиотекикоторые, в свою очередь, скомпилированы и связаны с исполняющей средой VC9, и в этом случае вполне возможно связать остальную часть кода с VC10, если только библиотеки не предоставляют ни один из типов библиотек VC9 в своих интерфейсах.Я говорю «вполне может быть», это та область, которая полна ловушек и ловушек, и в целом я бы сказал, что вы должны использовать одну и ту же среду выполнения везде, где это возможно.Последнее, что вам нужно, это то, что компилятор не понимает, о какой версии std :: vector вы говорите (и вы можете гарантировать, что программисты тоже будут сбиты с толку, даже если вы сможете убедить компилятор и компоновщик разобраться).

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