Обновления Visual Studio 2012 перерыв С++ ABI?

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

Основные версии, такие как Visual С++ 2013, дают нам свободу менять и разбивать много вещей. Просто мы не можем отправить этот материал в Обновление.

Q5: Как насчет исправлений? Можем ли мы получить их в обновлении?

A5: Это интересный вопрос, потому что ответ зависит от моего выбора (тогда как в предыдущем вопросе я не был бы допущен к отправке такой перезаписи в Обновление, даже если бы захотел).

Каждая команда выбирает, какие исправления, которые они берут для "судового", для рассмотрения, чтобы быть включенными в обновление. Есть вещи, которые не позволят нам уйти (например, бинарные изменения прерывания запрещены за пределами основных версий), но в остальном нам дана широта для решения вопросов. Я лично уделяю приоритетное внимание пропускной способности за латентность - то есть, я предпочитаю отправлять большее количество исправлений в каждой основной версии, вместо того, чтобы отправлять меньшее количество исправлений (за тот же период времени) чаще в нескольких обновлениях.

Вот точные правила:

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

[надрез]

Итак, если вы играете по правилам STL, вам необходимо обеспечить следующее:

• Все объектные файлы и статические библиотеки, связанные в один двоичный файл (EXE/DLL), должны быть скомпилированы с той же основной версией. Мы добавили проверки компоновщика, так что несовпадение основных версий VS 2010+ приведет к возникновению жестких ошибок во время соединения, но если VS 2008 или ранее задействован, мы не сможем помочь вам (без временных машин). Поскольку ODR применяется здесь, вы действительно должны использовать тот же набор инструментов (то есть тот же уровень пакета обновления) для всех объектных файлов и статических библиотек. Например, мы исправили утечку памяти std::string между RTM RT 2010 и RT1, но если вы смешиваете RTM и SP1, результирующая двоичная система может или не может быть затронута утечкой. (Кроме того, вам нужно использовать те же настройки _ITERATOR_DEBUG_LEVEL и отладки/отладки, у нас есть ссылки для них.)
• Если у вас есть несколько двоичных файлов, загружаемых в один и тот же процесс, и они передают объекты стандартной библиотеки С++ друг к другу, эти двоичные файлы должны быть созданы с той же основной версией и настройками _ITERATOR_DEBUG_LEVEL (выпуск/debug должен совпадать, я забыл, если вы может уйти с несоответствием здесь). Важно отметить, что мы не можем обнаружить нарушения этого правила, поэтому вам следует следовать ему.
• Несколько двоичных файлов, интерфейсы которых являются чисто C или COM (или теперь WinRT), могут внутренне использовать разные основные версии, поскольку эти вещи гарантируют двоичную совместимость. Если ваши интерфейсы связаны с С++ Core Language (например, с виртуальными), но очень осторожны, чтобы никогда не упоминать какие-либо типы стандартной библиотеки С++, тогда вы, вероятно, все в порядке - компилятор действительно пытается избежать нарушения бинарной совместимости.

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

Нижняя строка - если вы собираете все 100% последовательно, вам просто не нужно беспокоиться об этом. Не играйте в микширующие игры, если вы можете избежать этого.