Visual C++ Language Conformance
- 13 minutes to read
-
Contributors
This topic summarizes the ISO C++03, C++11, C++14, C++17, and Draft C++20 language standards conformance of compiler features and Standard Library features for the C++ compiler in Visual Studio 2017 and earlier versions. Each compiler and standard library feature name links to the ISO C++ Standard proposal paper that describes the feature, if one is available at publication time. The Supported column lists the Visual Studio version in which support for the feature first appeared.
For details on conformance improvements and other changes in Visual Studio 2017, see C++ conformance improvements in Visual Studio 2017 and What's New for Visual C++ in Visual Studio 2017. For conformance changes in earlier versions, see Visual C++ change history and Visual C++ What's New 2003 through 2015. For current news from the C++ team, visit the Visual C++ team blog.
Note
There are no binary breaking changes between Visual Studio 2015 and Visual Studio 2017.
Compiler Features
| Feature Area | |
|---|---|
| C++17 Core Language Features (Defect Reports) | Supported |
| P0702R1 Fixing class template argument deduction for initializer-list ctors | VS 2017 15.7 17 |
| P0588R1 Simplifying implicit lambda capture | No |
| CWG 1581: When are constexpr member functions defined? | No |
| P0962R1 Relaxing the structured bindings customization point finding rules | No |
| P0962R2 Relaxing the range-for loop customization point finding rules | No |
| P0969R0 Allowing structured bindings to accessible members | No |
| Feature Area | |
|---|---|
| C++20 Core Language Features | Supported |
| P0306R4 Adding __VA_OPT__ for comma omission and comma deletion | No |
| P0329R4 Designated initialization | No |
| P0409R2 Allowing lambda-capture [=, this] | No |
| P0428R2 Familiar template syntax for generic lambdas | No |
| P0683R1 Default member initializers for bit-fields | No |
| P0704R1 Fixing const lvalue ref-qualified pointers to members | No |
| P0734R0 Concepts | No |
Standard Library Features
A group of papers listed together indicates that a feature was voted into the Standard, and then one or more papers to improve or expand that feature were also voted in. These features are implemented together.
Supported values
No means not yet implemented.
Partial means the implementation in Visual Studio 2017 is incomplete. For more details, see the Notes section.
N/A means the proposal papers do not describe features. These papers altered the language of the standard, but didn’t create any work for implementers. They’re listed here for completeness.
VS 2010 indicates features that are supported in Visual Studio 2010.
VS 2013 indicates features that are supported in Visual Studio 2013.
VS 2015 indicates features that are supported in Visual Studio 2015 RTM.
VS 2015.2 and VS 2015.3 indicate features that are supported in Visual Studio 2015 Update 2 and Visual Studio 2015 Update 3, respectively.
VS 2017 indicates features that are supported in Visual Studio 2017 RTM.
VS 2017 15.3 indicates features that are supported in Visual Studio 2017 version 15.3.
VS 2017 15.5 indicates features that are supported in Visual Studio 2017 version 15.5.
VS 2017 15.7 indicates features that are supported in Visual Studio 2017 version 15.7.
Notes
A In /std:c++14 mode, dynamic exception specifications remain unimplemented, and throw() is still treated as a synonym for __declspec(nothrow). In C++17, dynamic exception specifications were mostly removed by P0003R5, leaving one vestige: throw() is deprecated and required to behave as a synonym for noexcept. In /std:c++17 mode, MSVC now conforms to the Standard by giving throw() the same behavior as noexcept, i.e. enforcement via termination.
The compiler option /Zc:noexceptTypes- requests our old behavior of __declspec(nothrow). It’s likely that throw() will be removed in C++20. To help with migrating code in response to these changes in the Standard and our implementation, new compiler warnings for exception specification issues have been added under /std:c++17 and /permissive-.
B Supported in /permissive- mode in Visual Studio 2017 version 15.7. See Two-phase name lookup support comes to MSVC for more information.
C The compiler’s support for Expression SFINAE has been sufficient for the Standard Library since Visual Studio 2015 Update 2. Supported in Visual Studio 2017 15.7 regardless of whether /permissive- mode is set. Some bugs remain to be fixed. The “unique tag type” workaround is no longer necessary, and we’ve removed this workaround from our STL implementation.
D The compiler’s support for C99 Preprocessor rules is incomplete in Visual Studio 2017. Variadic macros are supported, but there are many bugs in the preprocessor’s behavior. We are overhauling the preprocessor, and will experimentally ship those changes under the /permissive- mode soon.
E This is marked as Not Applicable because compilers are permitted, but not required, to support extended integer types. Like GCC and Clang, we’ve chosen not to support them.
F Similarly, this is marked as Not Applicable because compilers are permitted, but not required, to implement this optimization.
G Supported under /std:c++14 with a suppressible warning.
J Features that were not completed in Visual Studio 2015 are broken out elsewhere in this table.
K This is a completely new implementation, incompatible with the
previous std::experimental version, necessitated by symlink support, bug fixes, and changes in standard-required behavior. Currently, including <filesystem> provides the new std::filesystem and the previous std::experimental::filesystem, and including <experimental/filesystem> provides only the old experimental implementation. The experimental implementation will be REMOVED in the next ABI-breaking release of the libraries.
L Supported by a compiler intrinsic.
14 These C++17/20 features are always enabled, even when /std:c++14 (the default) is specified. This is either because the feature was implemented before the introduction of the /std options, or because conditional implementation was undesirably complex.
17 These features are enabled by the /std:c++17 (or /std:c++latest) compiler option.
byte std::byte is enabled by /std:c++17 (or /std:c++latest), but because it can conflict with the Windows SDK headers in some cases, it has a fine-grained opt-out macro. It can be disabled by defining _HAS_STD_BYTE as 0.
C11 The Universal CRT implemented the parts of the C11 Standard Library that are required by C++17, with the exception of C99 strftime() E/O alternative conversion specifiers, C11 fopen() exclusive mode, and C11 aligned_alloc(). The latter is unlikely to be implemented, because C11 specified aligned_alloc() in a way that's incompatible with the Microsoft implementation of free(), namely, that free() must be able to handle highly aligned allocations.
rem Features removed when the /std:c++17 (or /std:c++latest) compiler option is specified. These features have opt-out macros: _HAS_AUTO_PTR_ETC, _HAS_FUNCTION_ALLOCATOR_SUPPORT, _HAS_OLD_IOSTREAMS_MEMBERS, and _HAS_UNEXPECTED.
charconv from_chars() and to_chars() are available for integers. We’re currently working on floating-point from_chars(), to be followed by floating-point to_chars().
parallel C++17’s parallel algorithms library is complete. Note that this doesn’t mean every algorithm is parallelized in every case; the most important algorithms have been parallelized and execution policy signatures are provided even where algorithms are not parallelized. Our STL implementation’s central internal header, yvals.h, contains the following “Parallel Algorithms Notes”: C++ allows an implementation to implement parallel algorithms as calls to the serial algorithms. This implementation parallelizes several common algorithm calls, but not all.
The following algorithms are parallelized:
- adjacent_difference, adjacent_find, all_of, any_of, count, count_if, equal, exclusive_scan, find, find_end, find_first_of, find_if, for_each, for_each_n, inclusive_scan, mismatch, none_of, reduce, remove, remove_if, search, search_n, sort, stable_sort, transform, transform_exclusive_scan, transform_inclusive_scan, transform_reduce.
The following are not presently parallelized:
- No apparent parallelism performance improvement on target hardware; all algorithms which merely copy or permute elements with no branches are typically memory bandwidth limited:
- copy, copy_backward, copy_n, fill, fill_n, move, move_backward, remove, remove_if, replace, replace_if, reverse, reverse_copy, rotate, rotate_copy, swap_ranges
- Confusion over user parallelism requirements exists; likely in the above category anyway:
- generate, generate_n
- Effective parallelism suspected to be infeasible:
- partial_sort, partial_sort_copy
- Not yet evaluated; parallelism may be implemented in a future release and is suspected to be beneficial:
- copy_if, includes, inplace_merge, is_heap, is_heap_until, is_partitioned, is_sorted, is_sorted_until, lexicographical_compare, max_element, merge, min_element, minmax_element, nth_element, partition_copy, remove_copy, remove_copy_if, replace_copy, replace_copy_if, set_difference, set_intersection, set_symmetric_difference, set_union, stable_partition, unique, unique_copy
See also
C++ Language Reference
C++ Standard Library
C++ conformance improvements in Visual Studio 2017
What's New for Visual C++ in Visual Studio 2017
Visual C++ change history 2003 through 2015
Visual C++ What's New 2003 through 2015
Visual C++ team blog