Microsoft C/C++-Sprachkonformität nach Visual Studio-Version
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.
Ausführliche Informationen zu Konformitätsverbesserungen finden Sie im Artikel zu Verbesserungen der C++-Konformität in Visual Studio. Eine Liste weiterer Änderungen finden Sie unter Neuerungen bei Visual C++ in Visual Studio. Kompatibilitätsänderungen in früheren Versionen finden Sie unter Änderungsverlauf von Visual C++ von 2003 bis 2015 und Visual C++ What's New 2003 through 2015 (Visual C++ – Neuerungen von 2003 bis 2015). Aktuelle Nachrichten vom C++-Team finden Sie im C++-Teamblog.
Hinweis
Es gibt keine binären Breaking Changes zwischen Visual Studio 2015, 2017, 2019 und 2022. Weitere Informationen finden Sie unter Binärkompatibilität von C++ zwischen Visual Studio-Versionen.
C++-Compilerfeatures
Standardbibliotheksfeatures von C++
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> |
VS 2015 |
Unterstützung komplexer Zahlen in <complex.h> |
Partiell in VS 2015 K |
Typgenerische mathematische Funktionen <tgmath.h> |
VS 2019 16.8 2104 |
Zusätzliche Gleitkommamerkmale <float.h> |
VS 2015 |
printf-Spezifizierer für hexadezimale Gleitkommazahlen %A , %a |
VS 2015 |
Erweiterte Integertypen <inttypes.h> , <stdint.h> |
VS 2015 |
vscanf -Familie in <stdio.h> und <wchar.h> |
VS 2015 |
Neue mathematische Funktionen in <math.h> |
VS 2015 |
Behandlung von Fehlerbedingungen der mathematischen Bibliothek(math_errhandling ) |
VS 2015 |
Zugriff auf Gleitkommaumgebung <fenv.h> |
VS 2015 |
%lf -Konvertierungsspezifizierer für printf |
VS 2015 |
snprintf -Funktionsfamilie in <stdio.h> |
VS 2015 |
boolean -Typ in <stdbool.h> |
VS 2015 |
va_copy -Makro |
VS 2015 |
Zusätzliche strftime -Konvertierungsspezifizierer |
Partiell in VS 2015 L |
Standardbibliotheksfeatures von C11 | Unterstützt |
Ausrichtungsspezifizierer <stdalign.h> |
VS 2019 16.8 C11, 2104 |
aligned_alloc |
Nein M |
Keine Rückgabespezifizierer <stdnoreturn.h> |
VS 2019 16.8 C11, 2104 |
Threadunterstützung <threads.h> |
No |
Atomic-Unterstützung <stdatomic.h> |
No |
char16_t , char32_t <uchar.h> |
VS 2019 16.8 C11 |
gets() wurde entfernt |
VS 2019 16.8 C11, N |
gets_s() |
VS 2019 16.8 C11 |
Schnittstellen für Bindungsprüfung (*_s -APIs) |
Partiell in VS 2015 C11, O |
fopen "x" -Option |
VS 2019 16.8 C11 |
Statische Assertionen | VS 2019 16.8 C11, 2104 |
quick_exit |
VS 2019 16.8 C11 |
<complex.h> -Makros |
VS 2019 16.8 C11 |
Gleitkommamerkmale <float.h> |
VS 2019 16.8 C11 |
Unterstützte Werte
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.
B Wird im Modus /permissive-
in Visual Studio 2017, Version 15.7 unterstützt. Weitere Informationen finden Sie unter Two-phase name lookup support comes to MSVC
.
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.
D Unterstützt unter /std:c++14
mit der 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 werden parallelisiert:
adjacent_difference
,adjacent_find
, ,all_of
,count
count_if
inclusive_scan
for_each
find_first_of
find
exclusive_scan
equal
find_end
find_if_not
any_of
for_each_n
find_if
, ,transform_inclusive_scan
transform_exclusive_scan
is_heap
is_heap_until
is_partitioned
is_sorted
is_sorted_until
mismatch
none_of
partition
reduce
remove
remove_if
replace
replace_if
search
search_n
set_difference
set_intersection
sort
stable_sort
transform
transform_reduce
Die folgenden Algorithmen sind derzeit nicht parallelisiert:
- Diese Algorithmen zeigen keine nennenswerte Verbesserung der Leistung durch Parallelität auf der Zielhardware. Alle Algorithmen, die lediglich Elemente ohne Verzweigungen kopieren oder permutieren, sind in der Regel auf die Speicherbandbreite beschränkt:
copy
,copy_n
, ,fill
,fill_n
,reverse
move
,reverse_copy
,rotate
, ,rotate_copy
,shift_left
, ,shift_right
swap_ranges
- Für diese Algorithmen, die wahrscheinlich in der obigen Kategorie sind, gibt es Verwirrung über die Anforderungen an den Benutzerparallelismus:
generate
,generate_n
- Effektive Parallelität dieser Algorithmen kann nicht zu beachten sein:
partial_sort
,partial_sort_copy
- Diese Algorithmen wurden noch nicht ausgewertet. Die Bibliothek kann Parallelität in einer zukünftigen Version implementieren:
copy_if
,includes
, ,inplace_merge
,lexicographical_compare
,merge
min_element
max_element
,minmax_element
,nth_element
, ,stable_partition
unique
partition_copy
remove_copy
remove_copy_if
replace_copy
replace_copy_if
set_symmetric_difference
set_union
unique_copy
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.
I 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 strftime
E
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 _aligned_malloc
und _aligned_free
zur 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 Begrenzungsprü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 Breaking Change der Quelle. 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 Compileroption /std:c++latest
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, Version 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 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 den Windows SDK-Build 10.0.20348.0 (Version 2104) oder höher.
Siehe auch
C++-Programmiersprachenreferenz
C++-Standardbibliothek
Verbesserungen der C++-Konformität in Visual Studio 2015
Neuerungen bei Visual C++ in Visual Studio
Änderungsverlauf von Visual C++ von 2003 bis 2015
Visual C++: Neuerungen von 2003 bis 2015
C++-Teamblog
Feedback
https://aka.ms/ContentUserFeedback.
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unterFeedback senden und anzeigen für