Czy aktualizacje programu Visual Studio 2012 przerywają C++ ABI?

Question

Kiedy Microsoft początkowo opublikował Visual Studio 2012 we wrześniu 2012 r., Ogłosił swój plan udostępniania aktualizacji dla Visual Studio w bardziej regularny sposób. Od tego czasu wydali Visual Studio 2012 Update 1 (Visual Studio 2012.1) w listopadzie 2012 roku i Visual Studio 2012 Update 2 (Visual Studio 2012.2) w kwietniu 2013 roku.

Moje pytanie brzmi: Czy aktualizacje wprowadziły jakiekolwiek zmiany do ABI C++ (w odniesieniu do początkowej wersji VS2012)? Czy można bezpiecznie łączyć różne wersje VS2012 z .lib?

Przez pewien czas przeszukiwałem Internet i nie mogłem znaleźć żadnego oświadczenia firmy Microsoft. Jakiś numer sources wspomina, że ​​niektóre błędy w generowaniu kodu C++ zostały naprawione, ale przypuszczam, że to nie oznacza zmiany ABI?

Answer 1

Wreszcie znalazłem odpowiedzi na moje pytanie w Stephana T. Lavavej na blogu C++11/14 STL Features, Fixes, And Breaking Changes In VS 2013:

Mechanizm VS Update jest głównie dla wysyłać wysokim priorytecie poprawki błędów, nie dla wysyłać nowe funkcje, zwłaszcza masowe przepisywanie z przełamaniem zmian (które są powiązane z równie masywnymi zmianami kompilatora).

Główne wersje, takie jak Visual C++ 2013, dają nam swobodę zmiany i łamania wielu rzeczy. Po prostu nie możemy wysłać tych rzeczy w aktualizacji.

P5: A co z poprawkami błędów? Czy możemy uzyskać te aktualizacje?

A5: To interesujące pytanie, ponieważ odpowiedź zależy od moich wyborów (podczas gdy w poprzednim pytaniu, nie pozwoliłbym na wysłanie takiego przepisu w Aktualizacji, nawet gdybym chciał).

Każda drużyna ma wybór poprawek, które wprowadzą do "pokoju pokładowego", aby uwzględnić je w aktualizacji. Są rzeczy, których shiproom nie pozwoli nam uciec (np. zmiany binarne są zabronione poza głównymi wersjami), ale w przeciwnym razie otrzymujemy swobodę w decydowaniu. Osobiście przypisuję pierwszeństwo przepustowości w związku z opóźnieniami - tzn. Wolę przesyłać większą liczbę poprawek w każdej większej wersji, zamiast częstszego wysyłania mniejszej liczby poprawek (w tym samym okresie) w wielu aktualizacjach.

Answer 2

Stephan T. Lavavej, kluczowy autor realizacji STL Visual C++ 's rozplanowany zasady w tym Reddit thread:

Oto dokładne zasady:

Jeśli zawierać żadnych nagłówków C++ biblioteki standardowej, musisz grać według jego zasad i celowo łamamy zgodność binarną pomiędzy głównymi wersjami (ale zachowujemy ją pomiędzy poprawkami i dodatkami Service Pack). Wszelkie zmiany reprezentacji (w tym między innymi dodawanie/usuwanie członków danych) łamią kompatybilność binarną, dlatego tak się zawsze dzieje i dlaczego z zazdrością strzegamy tego prawa.

[ciach]

Tak więc, jeśli grasz w przepisach STL jest, trzeba upewnić się, co następuje:

• wszystkie pliki obiektów i bibliotek statycznych połączonych w jeden binarny (EXE/DLL) musi być skompilowany z tą samą główną wersją. Dodaliśmy sprawdzenia linkera, aby niezgodne wersje główne VS 2010+ wywoływały trudne błędy w czasie łączenia, ale jeśli VS 2008 lub wcześniejszy jest zaangażowany, nie możemy Ci pomóc (nie ma maszyn czasu). Ponieważ ODR ma zastosowanie tutaj, naprawdę powinieneś używać tego samego zestawu narzędzi (to jest tego samego poziomu Service Pack) dla wszystkich plików obiektów i bibliotek statycznych. Na przykład naprawiliśmy przeciek pamięci std :: string między VS 2010 RTM i SP1, ale jeśli miksujemy RTM i SP1, wynikowy plik binarny może, ale nie musi, być narażony na wyciek. (Dodatkowo musisz używać tych samych ustawień _ITERATOR_DEBUG_LEVEL i release/debug, teraz mamy sprawdzanie linkera.)
• Jeśli masz wiele plików binarnych załadowanych do tego samego procesu i przekazują one do siebie obiekty ze standardowej biblioteki C++ , te pliki binarne muszą być zbudowane z tą samą główną wersją i ustawieniami _ITERATOR_DEBUG_LEVEL (wersja/debug powinna również pasować, zapomniałem, czy można tu uniknąć niedopasowania). Co ważne, nie możemy wykryć naruszeń tej zasady, więc wybór należy do Ciebie.
• Wiele plików binarnych, których interfejsy to wyłącznie C lub COM (lub teraz WinRT) może wewnętrznie używać różnych wersji głównych, ponieważ gwarantują one zgodność binarną. Jeśli twoje interfejsy obejmują język rdzeniowy C++ (na przykład rzeczy z wirtualnymi), ale są bardzo ostrożne, aby nigdy nie wspominać o żadnych typach bibliotek standardowych C++, to prawdopodobnie jesteś w porządku - kompilator naprawdę stara się unikać łamania kompatybilności binarnej.

Należy jednak zauważyć, że gdy wiele plików binarnych załadowanych do pojedynczego procesu zostanie skompilowanych z różnymi wersjami głównymi, prawie na pewno skończy się wiele CRT załadowanych do procesu, co jest niepożądane.

Dolna linia - jeśli kompilujesz wszystko w 100% konsekwentnie, po prostu nie musisz się o nic martwić.Nie graj w gry miksujące, jeśli możesz tego uniknąć.