Microsoft C/C++-Sprachkonformität nach Visual Studio-Version
Artikel
Die Standardkonformität für den Microsoft C/C++-Compiler in Visual Studio (MSVC) ist in Bearbeitung. Nachfolgend finden Sie eine Zusammenfassung der C- und C++-ISO-Standardsprache und der Bibliothekskonformität geordnet nach Visual Studio-Versionen. Jeder Name eines Features im C++-Compiler und in der Standardbibliothek verweist auf das C++-ISO-Standardvorschlagsdokument, in dem das Feature beschrieben ist, falls zum Zeitpunkt der Veröffentlichung ein solches Dokument verfügbar ist. Die Spalte Unterstützt gibt die Visual Studio-Version an, in der das Feature zum ersten Mal unterstützt wurde.
Eine detailliertere Auflistung der Features und Fehlerkorrekturen der Standardbibliothek nach Produktversionen ist auf der GitHub-Seite „Microsoft/STL > Changelog“ verfügbar.
Eine Gruppe von Dokumenten, die zusammen aufgelistet sind, gibt ein Standardfeature zusammen mit mindestens einer genehmigten Verbesserung oder Erweiterung an. Diese Funktionen werden zusammen implementiert.
Standardbibliotheksfeatures von C
Funktion
Unterstützt
Standardbibliotheksfeatures von C99
Unterstützt
Makros für alternative Schreibweisen <iso646.h>
VS 2015
Unterstützung von Breitzeichen <wchar.h> und <wctype.h>
Nein Noch nicht implementiert. Partiell Die Implementierung ist unvollständig. Weitere Informationen finden Sie im Abschnitt Hinweise. VS 2010 Unterstützt in Visual Studio 2010. VS 2013 Unterstützt in Visual Studio 2013. VS 2015 Unterstützt in Visual Studio 2015 (RTW). VS 2015.2 und VS 2015.3 geben Funktionen an, die in Visual Studio 2015 Update 2 und Visual Studio 2015 Update 3 unterstützt werden. VS 2017 15.0 Unterstützt in Visual Studio 2017, Version 15.0 (RTW) VS 2017 15.3 Unterstützt in Visual Studio 2017, Version 15.3 VS 2017 15.5 Unterstützt in Visual Studio 2017, Version 15.5 VS 2017 15.7 Unterstützt in Visual Studio 2017, Version 15.7 VS 2019 16.0 Unterstützt in Visual Studio 2019, Version 16.0 (RTW) VS 2019 16.1 Unterstützt in Visual Studio 2019, Version 16.1 VS 2019 16.2 Unterstützt in Visual Studio 2019, Version 16.2 VS 2019 16.3 Unterstützt in Visual Studio 2019, Version 16.3 VS 2019 16.4 Unterstützt in Visual Studio 2019, Version 16.4 VS 2019 16.5 Unterstützt in Visual Studio 2019, Version 16.5 VS 2019 16.6 Unterstützt in Visual Studio 2019, Version 16.6 VS 2019 16.7 Unterstützt in Visual Studio 2019, Version 16.7 VS 2019 16.8 Unterstützt in Visual Studio 2019, Version 16.8 VS 2019 16.9 Unterstützt in Visual Studio 2019, Version 16.9 VS 2019 16.10 Unterstützt in Visual Studio 2019, Version 16.10. VS 2022 17.0 Unterstützt in Visual Studio 2022, Version 17.0 VS 2022 17.1 Unterstützt in Visual Studio 2022 Version 17.1 VS 2022 17.2 Unterstützt in Visual Studio 2022 Version 17.2 VS 2022 17.3 Unterstützt in Visual Studio 2022 Version 17.3 VS 2022 17.4 Unterstützt in Visual Studio 2022 Version 17.4 VS 2022 17.5 Unterstützt in Visual Studio 2022, Version 17.5.
Hinweise
A Im Modus /std:c++14 werden dynamische Ausnahmespezifikationen nicht implementiert, und throw() wird weiterhin als Synonym von __declspec(nothrow) behandelt. In C++17 wurden dynamische Ausnahmespezifikationen größtenteils durch P0003R5 entfernt, bis auf eine: throw() ist als veraltet markiert und muss sich wie ein Synonym von noexcept verhalten. Im Modus /std:c++17 entspricht MSVC nun dem Standard, da throw() das gleiche Verhalten wie noexcept aufweist (d. h. Erzwingung durch Beenden).
Die Compileroption /Zc:noexceptTypes fordert das alte Verhalten von __declspec(nothrow) an. Es ist wahrscheinlich, dass throw() in einer zukünftigen Version von C++ entfernt wird. Es wurden neue Compilerwarnungen für Probleme mit Ausnahmespezifikationen unter /std:c++17 und /permissive- hinzugefügt, um die Codemigration aufgrund dieser Änderungen in der Standard- und Microsoft-Implementierung zu erleichtern.
C Ab Visual Studio 2019, Version 16.6 implementiert der Compiler den C99-Präprozessor vollständig über die /Zc:preprocessor-Option. (In den Visual Studio 2017-Versionen 15.8 bis 16.5 unterstützt der Compiler den standardmäßigen C99-Präprozessor über die Compileroption /experimental:preprocessor.) Diese Option ist standardmäßig aktiviert, wenn die Compileroption /std:c11 oder /std:c17 angegeben ist.
G Unterstützt unter /std:c++14, mit einer unterdrückbaren Warnung (C4984).
E Die Implementierung ist ausreichend, um die C++20-Standardbibliothek zu unterstützen. Für eine vollständige Implementierung ist eine binäre Breaking Change erforderlich.
F Diese Features werden entfernt, wenn die Compileroption /std:c++17 oder höher angegeben wird. Um diese Features wieder zu aktivieren (um die Umstellung auf neuere Sprachmodi zu vereinfachen), können diese Makros verwendet werden: _HAS_AUTO_PTR_ETC, _HAS_FUNCTION_ALLOCATOR_SUPPORT, _HAS_OLD_IOSTREAMS_MEMBERS und _HAS_UNEXPECTED.
G Die Bibliothek mit parallelen Algorithmen von C++17 ist vollständig. „Vollständig“ bedeutet nicht, dass jeder Algorithmus in jedem Fall parallelisiert wird. Die wichtigsten Algorithmen wurden parallelisiert. Ausführungsrichtliniensignaturen werden auch dann bereitgestellt, wenn die Implementierung Algorithmen nicht parallelisiert. Der zentrale interne Header der Implementierung, <yvals_core.h>, enthält die folgenden Hinweise zu parallelen Algorithmen: C++ lässt zu, dass eine Implementierung parallele Algorithmen als Aufrufe serieller Algorithmen implementiert. Diese Implementierung parallelisiert einige aber nicht alle gängigen Algorithmusaufrufe.
Die folgenden Algorithmen sind derzeit nicht parallelisiert:
Diese Algorithmen zeigen keine nennenswerte Verbesserung der Leistung durch Parallelität auf der Zielhardware. Alle Algorithmen, die Elemente ohne Branches nur kopieren oder verschieben, verfügen normalerweise über eine Begrenzung der Arbeitsspeicherbandbreite:
Für diese Algorithmen gibt es Verwirrung über die Anforderungen an die Benutzerparallelität, die ohnehin wahrscheinlich in der obigen Kategorie vorhanden sind:
generate, generate_n
Eine effektive Parallelität dieser Algorithmen ist möglicherweise nicht realisierbar:
partial_sort, partial_sort_copy
Diese Algorithmen wurden noch nicht ausgewertet. In einem zukünftigen Release könnte die Bibliothek eine Parallelität implementieren:
H Dies ist eine völlig neue Implementierung, die nicht mit der vorherigen std::experimental-Version kompatibel ist. Sie ist aufgrund von Symlink-Unterstützung, Fehlerbehebungen und Änderungen des erforderlichen Standardverhaltens erforderlich. Derzeit stellt <filesystem> sowohl das neue std::filesystem als auch das frühere std::experimental::filesystem zur Verfügung. Der <experimental/filesystem>-Header stellt lediglich die alte experimentelle Implementierung zur Verfügung. Gehen Sie von der Entfernung der experimentellen Implementierung im nächsten ABI-Breaking Release der Bibliotheken aus.
G Unterstützt durch eine intrinsische Compilerfunktion.
Jstd::byte wird durch /std:c++17 oder höher aktiviert. Da jedoch in einigen Fällen Konflikte mit den Windows SDK-Headern auftreten können, ist ein differenziertes Makro für die Abwahl vorhanden. Definieren Sie _HAS_STD_BYTE als 0, um dies zu deaktivieren.
K MSVC unterstützt nicht das Schlüsselwort _Complex oder native komplexe Typen. Die universelle CRT <complex.h> verwendet implementierungsspezifische Makros, um denselben Effekt zu erzielen. Weitere Informationen finden Sie im Artikel zur Unterstützung komplexer mathematischer Berechnungen in C.
L Die universelle CRT implementiert nicht die alternativen Konvertierungsmodifizierer strftimeE und O. Diese Modifizierer werden ignoriert (%Oe verhält sich beispielsweise wie %e). Die Modifizierer werden von den zugrunde liegenden Gebietsschema-APIs nicht unterstützt.
M Die universelle CRT implementiert C11 aligned_alloc nicht, stellt aber und _aligned_malloc zur _aligned_free Verfügung. Da das Windows-Betriebssystem keine ausgerichteten Zuordnungen unterstützt, wird diese Funktion wahrscheinlich nicht implementiert.
N Die Deklaration wird entfernt, aber der Export für die Funktion bleibt aus Gründen der Abwärtskompatibilität erhalten.
O Bestimmte Funktionen zur Bindingsprüfung sind nicht implementiert, weisen andere Signaturen auf oder sind nicht Teil des C11- oder C17-Standards. Diese Funktionen sind nicht implementiert: abort_handler_s, ignore_handler_s, memset_s, set_constraint_handler_s, snprintf_s, snwprintf_s, strerrorlen_s, vsnwprintf_s. Diese Funktionen weisen andere Signaturen auf: gmtime_s, localtime_s, qsort_s, strtok_s, vsnprintf_s, wcstok_s. Diese Funktionen sind nicht im Standard enthalten: clearerr_s, fread_s.
P Die Unterstützung wurde in Visual Studio 2019 Version 16.10 hinzugefügt. Die Unterstützung für Clang wurde in Visual Studio 2022 Version 17.0 hinzugefügt.
Q: Dadurch werden auch declare_reachable, undeclare_reachable, declare_no_pointers, undeclare_no_pointers und get_pointer_safety entfernt. Diese Funktionen waren zuvor ohne Wirkung.
R: Dies ist ein häufiger Source Breaking Change. Allerdings wird Code mit vorher nicht definiertem Verhalten zur Runtime jetzt mit Compilerfehlern abgelehnt.
S-Eingabebereichsadapter und counted_iterator werden in VS 2022 17.0 implementiert. Ein zukünftiges Update auf Visual Studio 2019 Version 16.11 ist geplant, um diese Änderungen zu integrieren.
T<stdatomic.h> wird derzeit bei der C++-Kompilierung (/std:c++latest) unterstützt. Bei der C-Kompilierung (/std:c11 und /std:c17) wird dies noch nicht unterstützt.
14 Diese C++17- und C++20-Features sind immer aktiviert, auch wenn /std:c++14 (Standard) angegeben ist. Grund dafür ist entweder, dass das Feature vor der Einführung der /std -Optionen implementiert wurde oder dass die bedingte Implementierung unerwünscht komplex war.
17 Diese Features werden durch die Compileroption /std:c++17 oder höher aktiviert.
20 In Versionen bis Visual Studio 2019, Version 16.10 werden diese Features durch die /std:c++latest Compileroption aktiviert. In Visual Studio 2019 Version 16.11 wurde die Compileroption /std:c++20 hinzugefügt, um diese Features zu aktivieren.
20abi Aufgrund der laufenden Nacharbeiten am C++20-Standard <format> sind die Formatierungsteile von <chrono> (die auf <format> beruhen) und die Bereichsfactorys sowie -adapter aus <ranges> (alles, was für das view-Konzept benötigt wird) nur unter /std:c++latest verfügbar. Gehen Sie davon aus, dass diese Features unter /std:c++20 nach der Vereinbarung mit WG21 vorliegen, sodass keine weiteren ABI-Breaking Changes erforderlich sind. Die verbleibenden Teile von <chrono> und die Algorithmen für die Bereiche werden ab Visual Studio 2019 Version 16.11 unter der Compileroption /std:c++20 aktiviert.
23: In Visual Studio 2022 17.0 und höher werden diese Features durch die Compileroption /std:c++latest aktiviert.
C11 Compilerunterstützung für C11 und C17 erfordert Visual Studio Version 2019, Version 16.8 oder höher. Sofern nicht anders angegeben, erfordert die C11- und C17-Bibliotheksunterstützung das Windows SDK-Build 10.0.20211.0 oder höher. Weitere Informationen zum Installieren der Unterstützung für C11 und C17 finden Sie unter Installieren der Unterstützung für C11 und C17 in Visual Studio.
DR Diese Features sind in allen /std-Compileroptionsmodi von C++ aktiviert. Der Ausschuss für den C++-Standard hat diese Änderung als einen rückwirkenden Fehlerbericht zu C++11 und allen späteren Versionen übernommen.
2104 Die C11-Bibliotheksunterstützung für dieses Feature erfordert das Windows SDK-Build 10.0.20348.0 (Version 2104) oder höher.