Conformité du langage Microsoft C/C++ par version de Visual Studio
La mise en conformité aux normes du compilateur Microsoft C/C++ dans Visual Studio (MSVC) est un travail en cours. Voici une synthèse de la conformité à la norme ISO de la bibliothèque et du langage C et C++ par version de Visual Studio. Chaque nom de fonctionnalité du compilateur C++ et de bibliothèque standard comporte un lien vers le document de proposition de la norme ISO C++ décrivant la fonctionnalité, quand celui-ci est disponible au moment de la publication. La colonne Prise en charge indique la première version de Visual Studio à prendre en charge la fonctionnalité.
Pour plus d’informations sur les améliorations de la conformité, consultez Améliorations de la conformité de C++ dans Visual Studio. Pour obtenir la liste des autres modifications, consultez Nouveautés de Visual C++ dans Visual Studio. Pour passer en revue les changements de conformité dans les versions antérieures, consultez Historique des modifications de Visual C++ et Nouveautés de Visual C++ entre 2003 et 2015. Pour connaître l’actualité de l’équipe C++, visitez le blog de l’équipe C++.
Notes
Aucun changement cassant de binaire n’a eu lieu entre Visual Studio 2015, 2017, 2019 et 2022. Pour plus d’informations, consultez Compatibilité de binaire C++ entre les versions de Visual Studio
Fonctionnalités du compilateur C++
Fonctionnalités de bibliothèque standard C
Une liste plus détaillée des fonctionnalités de bibliothèque standard et des correctifs de bogues par version de produit est disponible sur la page GitHub Microsoft STL wiki Changelog.
Un groupe d’articles répertoriés ensemble indiquent une fonctionnalité Standard ainsi qu’une ou plusieurs améliorations ou expansions approuvées. Ces fonctionnalités sont implémentées ensemble.
Fonctionnalités de bibliothèque standard C
Fonctionnalité | Prise en charge |
---|---|
Fonctionnalités de bibliothèque standard C99 | Pris en charge |
Autres macros d’orthographe <iso646.h> |
VS 2015 |
Prise en charge des caractères larges <wchar.h> et <wctype.h> |
VS 2015 |
Prise en charge complexe dans <complex.h> |
Partielle dans VS 2015 K |
Fonctions mathématiques de type générique <tgmath.h> |
VS 2019 16.8 2104 |
Caractéristiques de virgule flottante supplémentaires <float.h> |
VS 2015 |
Spécificateurs printf de virgule flottante hexadécimale %A , %a |
VS 2015 |
Types entiers étendus <inttypes.h> , <stdint.h> |
VS 2015 |
Famillevscanf dans <stdio.h> et <wchar.h> |
VS 2015 |
Nouvelles fonctions mathématiques dans <math.h> |
VS 2015 |
Traitement des conditions d’erreur de bibliothèque mathématique (math_errhandling ) |
VS 2015 |
Accès à l’environnement à virgule flottante <fenv.h> |
VS 2015 |
Spécificateur de conversion %lf pour printf |
VS 2015 |
Famille de fonctions snprintf dans <stdio.h> |
VS 2015 |
Type boolean dans <stdbool.h> |
VS 2015 |
Macro va_copy |
VS 2015 |
Spécificateurs de conversion strftime supplémentaires |
Partielle dans VS 2015 L |
Fonctionnalités de bibliothèque standard C11 | Pris en charge |
Spécificateurs d’alignement <stdalign.h> |
VS 2019 16.8 C11, 2104 |
aligned_alloc |
Non M |
Aucun spécificateur de retour <stdnoreturn.h> |
VS 2019 16.8 C11, 2104 |
Prise en charge du threading <threads.h> |
Oui |
Prise en charge atomique <stdatomic.h> |
Expérimental |
char16_t , char32_t <uchar.h> |
VS 2019 16.8 C11 |
gets() supprimé |
VS 2019 16.8 C11, N |
gets_s() |
VS 2019 16.8 C11 |
Interfaces de vérification des limites (API *_s ) |
Partielle dans VS 2015 C11, O |
Option fopen "x" |
VS 2019 16.8 C11 |
Assertions statiques | VS 2019 16.8 C11, 2104 |
quick_exit |
VS 2019 16.8 C11 |
Macros <complex.h> |
VS 2019 16.8 C11 |
Caractéristiques de virgule flottante <float.h> |
VS 2019 16.8 C11 |
Threads C11 <threads.h> |
VS 2022 17.8 C11 |
Valeurs prises en charge
Non Pas encore implémenté.
Partielle L’implémentation est incomplète. Pour plus d’informations, consultez la section Remarques.
VS 2010 Pris en charge dans Visual Studio 2010.
VS 2013 Pris en charge dans Visual Studio 2013.
VS 2015 Pris en charge dans Visual Studio 2015 (RTW).
Visual Studio 2015.2 et VS 2015.3 indiquent des fonctionnalités prises en charge dans Visual Studio 2015 Update 2 et Visual Studio 2015 Update 3, respectivement.
VS 2017 15.0 Pris en charge dans Visual Studio 2017 version 15.0 (RTW).
VS 2017 15.3 Pris en charge dans Visual Studio 2017 version 15.3.
VS 2017 15.5 Pris en charge dans Visual Studio 2017 version 15.5.
VS 2017 15.7 Pris en charge dans Visual Studio 2017 version 15.7.
VS 2019 16.0 Pris en charge dans Visual Studio 2019 version 16.0 (RTW).
VS 2019 16.1 Pris en charge dans Visual Studio 2019 version 16.1.
VS 2019 16.2 Pris en charge dans Visual Studio 2019 version 16.2.
VS 2019 16.3 Pris en charge dans Visual Studio 2019 version 16.3.
VS 2019 16.4 Pris en charge dans Visual Studio 2019 version 16.4.
VS 2019 16.5 Pris en charge dans Visual Studio 2019 version 16.5.
VS 2019 16.6 Pris en charge dans Visual Studio 2019 version 16.6.
VS 2019 16.7 Pris en charge dans Visual Studio 2019 version 16.7.
VS 2019 16.8 Pris en charge dans Visual Studio 2019 version 16.8.
VS 2019 16.9 Pris en charge dans Visual Studio 2019 version 16.9.
VS 2019 16.10 Pris en charge dans Visual Studio 2019 version 16.10.
VS 2022 17.0 Pris en charge dans Visual Studio 2022 version 17.0.
VS 2022 17.1 Pris en charge dans Visual Studio 2022 version 17.1.
VS 2022 17.2 Pris en charge dans Visual Studio 2022 version 17.2.
VS 2022 17.3 Pris en charge dans Visual Studio 2022 version 17.3.
VS 2022 17.4 Pris en charge dans Visual Studio 2022 version 17.4.
VS 2022 17.5 Pris en charge dans Visual Studio 2022 version 17.5.
Notes
A En mode /std:c++14
, les spécifications d’exceptions dynamiques restent non implémentées, et throw()
est toujours traité comme un synonyme de __declspec(nothrow)
. Dans C++17, la plupart des spécifications d’exceptions dynamiques ont été supprimées par P0003R5, sauf pour un vestige : throw()
est déconseillé et doit se comporter comme synonyme de noexcept
. En mode /std:c++17
, MSVC est désormais conforme à la norme en donnant à throw()
le même comportement que noexcept
, comme la mise en œuvre par terminaison.
L’option du compilateur /Zc:noexceptTypes
demande l’ancien comportement de __declspec(nothrow)
. Il est probable que throw()
sera supprimé dans une prochaine version de C++. Pour faciliter la migration de code en réponse à ces changements dans la norme et l’implémentation Microsoft, de nouveaux avertissements du compilateur pour les problèmes de spécification d’exception sont ajoutés sous /std:c++17
et /permissive-
.
B Pris en charge en mode /permissive-
dans Visual Studio 2017 version 15.7. Pour plus d’informations, consultez Two-phase name lookup support comes to MSVC
.
C Dans Visual Studio 2019 versions 16.6 et ultérieures, le compilateur implémente entièrement le préprocesseur C99 standard via l’option /Zc:preprocessor
. (Dans Visual Studio 2017 versions 15.8 à 16.5, le compilateur prend en charge le préprocesseur C99 standard via l’option /experimental:preprocessor
du compilateur.) Cette option est activée par défaut lorsque l’option /std:c11
du compilateur ou /std:c17
sont spécifiées.
D Pris en charge sous /std:c++14
avec un avertissement pouvant être supprimé, C4984
.
E L’implémentation est suffisante pour prendre en charge la bibliothèque standard C++20. Une implémentation complète nécessite un changement cassant de binaire.
F Fonctionnalités supprimées lorsque l’option /std:c++17
du compilateur ou ultérieur est spécifiée. Pour réactiver ces fonctionnalités (pour faciliter la transition vers des modes de langage plus récents), utilisez les macros _HAS_AUTO_PTR_ETC
, _HAS_FUNCTION_ALLOCATOR_SUPPORT
, _HAS_OLD_IOSTREAMS_MEMBERS
et _HAS_UNEXPECTED
.
G La bibliothèque d’algorithmes parallèles de C++17 est complète. Complète ne signifie pas que chaque algorithme est parallélisé dans tous chaque cas. Les algorithmes les plus importants ont été parallélisés. Les signatures de stratégie d’exécution sont fournies même lorsque l’implémentation ne parallélise pas les algorithmes. L’en-tête interne central, <yvals_core.h>
, contient les notes suivantes sur les algorithmes parallèles : C++ permet à une implémentation d’implémenter des algorithmes parallèles en tant qu’appels aux algorithmes de série. Cette implémentation parallélise plusieurs appels d’algorithme courants, mais pas tous.
Les algorithmes suivants sont parallélisés :
adjacent_difference
, ,all_of
mismatch
find_if_not
find_first_of
find
equal
count_if
count
exclusive_scan
find_end
find_if
is_sorted_until
is_partitioned
is_heap_until
inclusive_scan
adjacent_find
is_heap
for_each_n
any_of
for_each
is_sorted
none_of
, ,search
sort
set_intersection
stable_sort
set_difference
transform
transform_exclusive_scan
reduce
remove_if
transform_inclusive_scan
remove
replace
replace_if
search_n
partition
transform_reduce
Ces algorithmes ne sont pas actuellement parallélisés :
- Ces algorithmes ne montrent aucune amélioration notable des performances du parallélisme sur le matériel cible. Tous les algorithmes qui copient ou permutent simplement des éléments sans branches sont généralement limités par la bande passante de la mémoire :
copy
, ,copy_n
,fill_n
, ,reverse
shift_left
shift_right
reverse_copy
rotate_copy
rotate
move
fill
swap_ranges
- Une certaine confusion règne concernant les exigences de parallélisme pour ces algorithmes qui appartiennent probablement à la catégorie ci-dessus :
generate
,generate_n
- Le parallélisme efficace de ces algorithmes peut être irréalisable :
partial_sort
,partial_sort_copy
- Ces algorithmes n’ont pas encore été évalués. La bibliothèque pourrait implémenter le parallélisme dans une version ultérieure :
copy_if
,includes
,inplace_merge
,stable_partition
remove_copy_if
remove_copy
replace_copy
partition_copy
replace_copy_if
nth_element
unique
merge
set_union
min_element
set_symmetric_difference
minmax_element
lexicographical_compare
max_element
unique_copy
H Il s’agit d’une toute nouvelle implémentation, incompatible avec la version std::experimental
précédente, rendue nécessaire par la prise en charge de symlink, les correctifs de bogues et les changements de comportement requis par la norme. Actuellement, <filesystem>
fournit le nouveau std::filesystem
et le std::experimental::filesystem
précédent. L’en-tête <experimental/filesystem>
fournit uniquement l’ancienne implémentation expérimentale. Attendez-vous à la suppression de l’implémentation expérimentale dans la prochaine version en rupture avec ABI des bibliothèques.
I Pris en charge par une fonction intrinsèque du compilateur.
Jstd::byte
est activé par /std:c++17
ou version ultérieure, mais, étant donné qu’il peut entrer en conflit avec les en-têtes du SDK Windows dans certains cas, il comporte une macro de refus affinée. Pour le désactiver, définissez _HAS_STD_BYTE
en tant que 0
.
K MSVC ne prend pas en charge le mot clé _Complex
ni les types complexes natifs. Le CRT universel <complex.h>
utilise des macros spécifiques de l’implémentation pour obtenir le même effet. Pour plus d’informations, consultez Prise en charge des fonctions mathématiques complexes C.
L Le CRT universel n’implémente pas les modificateurs de conversion alternatifs strftime
E
et O
. Ces modificateurs sont ignorés (par exemple, %Oe
se comporte de la même façon que %e
). Les modificateurs ne sont pas pris en charge par les API de paramètres régionaux sous-jacentes.
M Le CRT universel n’implémente pas C11 aligned_alloc
, mais fournit _aligned_malloc
et _aligned_free
. Étant donné que le système d’exploitation Windows ne prend pas en charge les allocations alignées, il est peu probable que cette fonction soit implémentée.
N La déclaration est supprimée, mais l’exportation de la fonction reste à des fins de compatibilité descendante.
O Certaines fonctions de vérification des limites ne sont pas implémentées, ont des signatures différentes ou ne font pas partie de la norme C11 ou C17. Les fonctions suivantes ne sont pas implémentées : abort_handler_s
, ignore_handler_s
, memset_s
, set_constraint_handler_s
, snprintf_s
, snwprintf_s
, strerrorlen_s
, vsnwprintf_s
. Les fonctions suivantes fonctions ont des signatures différentes : gmtime_s
, localtime_s
, qsort_s
, strtok_s
, vsnprintf_s
, wcstok_s
. Les fonctions suivantes n’apparaissent pas dans la norme : clearerr_s
, fread_s
.
P La prise en charge a été ajoutée dans Visual Studio 2019 version 16.10. La prise en charge de Clang a été ajoutée dans Visual Studio 2022 version 17.0.
Q Cela supprime declare_reachable
, undeclare_reachable
, declare_no_pointers
, undeclare_no_pointers
, get_pointer_safety
. Auparavant, ces fonctions n’avaient aucun effet.
R Il s’agit d’un changement cassant de source courant. Toutefois, le code qui avait auparavant un comportement non défini au moment de l’exécution est maintenant rejeté avec des erreurs du compilateur.
S Les adaptateurs de plage d’entrée et counted_iterator
sont implémentés dans VS 2022 17.0. Une prochaine mise à jour de Visual Studio 2019 version 16.11 est prévue pour incorporer ces modifications.
T <stdatomic.h>
est actuellement pris en charge quand il est compilé en tant que C++ (/std:c++latest
). Il n’est pas encore pris en charge quand il est compilé en tant que C (/std:c11
et /std:c17
)
14 Ces fonctionnalités C++17 et C++20 sont toujours activées, même quand /std:c++14
(valeur par défaut) est spécifié. La raison à cela est soit que la fonctionnalité a été implémentée avant l’introduction des options /std
, soit que l’implémentation conditionnelle était trop complexe.
17 Ces fonctionnalités sont activées par l’option du compilateur /std:c++17
ou ultérieure.
20 Jusqu’à Visual Studio 2019 version 16.10, ces fonctionnalités sont activées par l’option du compilateur /std:c++latest
. Visual Studio 2019 version 16.11 a ajouté l’option du compilateur /std:c++20
pour activer ces fonctionnalités.
20abi En raison du travail post-publication en cours sur la norme C++20, <format>
, les parties mise en forme de <chrono>
(qui reposent sur <format>
), ainsi que les fabriques et adaptateurs de plage de <ranges>
(tout ce qui a besoin du concept view
) sont disponibles uniquement sous /std:c++latest
. Attendez-vous à ce que, pour ces fonctionnalités sous /std:c++20
, après qu’un accord aura été conclu avec WG21, aucun autre changement cassant en rupture avec ABI ne soit nécessaire. Les autres parties de <chrono>
et les algorithmes qui s’appliquent aux plages sont activés sous l’option du compilateur /std:c++20
dans Visual Studio 2019 versions 16.11 et ultérieures.
23 Dans Visual Studio 2022 versions 17.0 et ultérieures, ces fonctionnalités sont activées par l’option du compilateur /std:c++latest
.
C11 La prise en charge du compilateur pour C11 et C17 nécessite Visual Studio 2019 version 16.8 ou ultérieure. Sauf indication contraire, la prise en charge des bibliothèques C11 et C17 nécessite la build 10.0.20211.0 ou ultérieure du SDK Windows. Pour plus d’informations sur l’installation de la prise en charge de C11 et C17, consultez Installer la prise en charge de C11 et C17 dans Visual Studio.
DR Ces fonctionnalités sont activées dans tous les modes d’option /std
du compilateur C++. Le comité de la Norme C++ a adopté cette modification en tant que rapport de défaut rétroactif pour C++11 et toutes les versions ultérieures.
2104 La prise en charge de la bibliothèque C11 pour cette fonctionnalité nécessite la build SDK Windows 10.0.20348.0 (version 2104) ou ultérieure.
Voir aussi
Informations de référence sur le langage C++
Bibliothèque C++ standard
Améliorations de la conformité de C++ dans Visual Studio
Nouveautés de Visual C++ dans Visual Studio
Historique des modifications de Visual C++ entre 2003 et 2015
Nouveautés de Visual C++ entre 2003 et 2015
Blog de l’équipe C++