Czy aktualizacje Visual Studio 2012 łamią C++ ABI?

Question

Czy aktualizacje Visual Studio 2012 łamią C++ ABI?

Kiedy Microsoft po raz pierwszy wydał Visual Studio 2012 we wrześniu 2012 roku, ogłosił swój plan dostarczania aktualizacji dla Visual Studio na bardziej regularne. Od tego czasu firma wydała 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 jakieś zmiany w C++ ABI (w odniesieniu do początkowej wersji VS2012)? Czy to bezpieczne do linkowania .lib S różnych wersji VS2012?

Przeszukałem internet przez jakiś czas i nie mogłem znaleźć żadnego konkretnego oświadczenia od Microsoftu. Niektóre źródła wspominają, że niektóre błędy w generowaniu kodu C++ zostały naprawione, ale przypuszczam, że nie oznacza to zmiany ABI?

18

c++abi visual-studio-2012

Author: Bloops, 2013-04-05

Source

2 answers

Stephan T. Lavavej, kluczowy autor implementacji stl Visual C++określił reguły w tym wątku :

Oto dokładne zasady:

Jeśli dodajesz nagłówki bibliotek standardowych C++, musisz grać zgodnie z jej regułami, a my celowo łamiemy kompatybilność binarną między głównymi wersjami (ale zachowujemy ją między hotfixami i service Pack ' ami). Wszelkie zmiany reprezentacji (w tym, ale nie ograniczając się do dodawania/usuwania członków danych) break binary zgodność, dlatego tak się zawsze dzieje i dlatego zazdrośnie strzeżemy tego prawa.

[snip]

Więc, jeśli grasz według zasad STL, musisz upewnić się, że:

wszystkie pliki obiektowe i biblioteki statyczne połączone w jeden plik binarny (EXE / DLL) muszą być skompilowane z tą samą główną wersją. Dodaliśmy kontrole linkera, tak, że niedopasowanie VS 2010 + główne wersje spowoduje twarde błędy w czasie łącza, ale jeśli VS 2008 lub wcześniej jest zaangażowani nie możemy Ci pomóc (nie ma wehikułów czasu). Ponieważ ODR ma tu zastosowanie, naprawdę powinieneś używać tego samego zestawu narzędzi (tzn. tego samego poziomu dodatku service pack) dla wszystkich plików obiektowych i bibliotek statycznych. Na przykład, naprawiliśmy wyciek pamięci std:: string pomiędzy VS 2010 RTM i SP1, ale jeśli wymieszasz RTM i SP1, wyciek może mieć wpływ na wynikający plik binarny. (Dodatkowo musisz używać tych samych ustawień _ITERATOR_DEBUG_LEVEL i release/debug; mamy dla nich kontrole linkera teraz.)

Jeśli do tego samego procesu wczytanych jest wiele binariów, które przekazują sobie Obiekty biblioteki standardowej C++, te binaria muszą być zbudowane z tą samą główną wersją I ustawieniami _ITERATOR_DEBUG_LEVEL (release / debug też powinny pasować, zapominam, czy można uniknąć niedopasowania tutaj). Co ważne, nie możemy wykryć naruszenia tej zasady, więc do ciebie należy jej przestrzeganie.

wiele binariów, których interfejsy są czysto C lub COM (lub teraz WinRT), może wewnętrznie używaj różnych głównych wersji, ponieważ te rzeczy gwarantują kompatybilność binarną. Jeśli Twoje interfejsy zawierają rdzeń języka C++ (np. rzeczy z wirtualami), ale są bardzo ostrożne, aby nigdy nie wspominać o typach standardowych bibliotek C++, to prawdopodobnie jesteś w porządku-kompilator naprawdę stara się uniknąć łamania kompatybilności binarnej.

Zauważ jednak, że gdy wiele binariów załadowanych do jednego procesu zostanie skompilowanych z różnymi głównymi wersjami, prawie na pewno skończysz z wieloma CRT załadowanymi do procesu, co jest niepożądane.

Podsumowując - jeśli kompilujesz wszystko w 100% konsekwentnie, po prostu nie musisz się martwić o żadne z tych rzeczy. Nie graj w gry mieszające, jeśli możesz tego uniknąć.

13

Author: Eoin,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-04-11 14:10:38

score 7 · Accepted Answer

W końcu znalazłem odpowiedź na moje pytanie w wpisie Stephan T. Lavavej na blogu C++11/14 stl funkcje, poprawki i łamanie zmian w VS 2013:

Mechanizm VS Update służy przede wszystkim do wysyłania poprawek błędów o wysokim priorytecie, a nie do wysyłania nowych funkcji, szczególnie masowych przepisań z przerywającymi zmianami (które są powiązane z równie masowymi zmianami kompilatora).

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

P5: a co z poprawkami błędów? Możemy je podać w Aktualnościach?

A5: to ciekawe pytanie, ponieważ odpowiedź zależy od moich wyborów(podczas gdy w poprzednim pytaniu, nie pozwoliłbym wysłać takiej przeróbki w aktualizacji, nawet gdybym chciał).

Każda drużyna może wybrać, które poprawki wprowadzi do" shiproom", aby uwzględnić je w aktualizacji. Są rzeczy, których statek nie pozwoli nam uchodzi to na sucho (np. binarne zmiany łamiące są zabronione poza głównymi wersjami ), ale poza tym mamy swobodę decydowania o rzeczach. Osobiście ustalam priorytet przepustowości nad opóźnieniami-to znaczy wolę wysyłać większą całkowitą liczbę poprawek w każdej głównej wersji, zamiast wysyłać mniejszą całkowitą liczbę poprawek (w tym samym okresie czasu) częściej w wielu aktualizacjach.