Microsoft C/C++ language conformance by Visual Studio version

• 06/22/2021
• 26 minutes to read
• • c
  • f
  • n
  • j
  • m

Standards conformance for the Microsoft C/C++ compiler in Visual Studio (MSVC) is a work in progress. Here's a summary of our ISO Standard C and C++ language and library conformance by Visual Studio version. Each C++ compiler and standard library feature name links to the ISO Standard C++ 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, see C++ conformance improvements in Visual Studio. For a list of other changes, see What's New for Visual C++ in Visual Studio. 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 C++ team blog.

C++ compiler features

C++ Standard library features

A more detailed listing of Standard Library features and bug fixes by product version is available on the GitHub Microsoft STL wiki Changelog page.

A group of papers listed together indicates a Standard feature along with one or more approved improvements or expansions. These features are implemented together.

C Standard library features

Supported values

No Not yet implemented.
Partial The implementation is incomplete. For more information, see the Notes section.
VS 2010 Supported in Visual Studio 2010.
VS 2013 Supported in Visual Studio 2013.
VS 2015 Supported in Visual Studio 2015 (RTW).
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 15.0 Supported in Visual Studio 2017 version 15.0 (RTW).
VS 2017 15.3 Supported in Visual Studio 2017 version 15.3.
VS 2017 15.5 Supported in Visual Studio 2017 version 15.5.
VS 2017 15.7 Supported in Visual Studio 2017 version 15.7.
VS 2019 16.0 Supported in Visual Studio 2019 version 16.0 (RTW).
VS 2019 16.1 Supported in Visual Studio 2019 version 16.1.
VS 2019 16.2 Supported in Visual Studio 2019 version 16.2.
VS 2019 16.3 Supported in Visual Studio 2019 version 16.3.
VS 2019 16.4 Supported in Visual Studio 2019 version 16.4.
VS 2019 16.5 Supported in Visual Studio 2019 version 16.5.
VS 2019 16.6 Supported in Visual Studio 2019 version 16.6.
VS 2019 16.7 Supported in Visual Studio 2019 version 16.7.
VS 2019 16.8 Supported in Visual Studio 2019 version 16.8.
VS 2019 16.9 Supported in Visual Studio 2019 version 16.9.
VS 2019 16.10 Supported in Visual Studio 2019 version 16.10.

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, that is, enforcement via termination.

The compiler option /Zc:noexceptTypes requests our old behavior of __declspec(nothrow). It's likely that throw() will be removed in a future version of C++. 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. For more information, see Two-phase name lookup support comes to MSVC.

C Starting in Visual Studio 2019 version 16.6, the compiler fully implements the C99 preprocessor via the /Zc:preprocessor option. (Before version 16.6, starting in Visual Studio 2017 version 15.8, the compiler provides support for the C99 preprocessor via the /experimental:preprocessor compiler option.) This option is on by default when the compiler option /std:c11 or /std:c17 is specified.

D Supported under /std:c++14 with a suppressible warning, C4984.

E The implementation is sufficient to support the C++20 Standard Library. A complete implementation requires a binary breaking change.

F Features removed when the /std:c++17 or later compiler option is specified. To re-enable these features (to ease the transition to newer language modes), use these macros: _HAS_AUTO_PTR_ETC, _HAS_FUNCTION_ALLOCATOR_SUPPORT, _HAS_OLD_IOSTREAMS_MEMBERS, and _HAS_UNEXPECTED.

G C++17's parallel algorithms library is complete. Complete 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 we don't parallelize algorithms. Our implementation's central internal header, <yvals_core.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, find_if_not, for_each, for_each_n, inclusive_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_exclusive_scan, transform_inclusive_scan, transform_reduce

These algorithms aren't presently parallelized:

• These algorithms show no noticeable parallelism performance improvement on target hardware. All algorithms that merely copy or permute elements with no branches are typically memory bandwidth limited:
  • copy, copy_n, fill, fill_n, move, reverse, reverse_copy, rotate, rotate_copy, shift_left, shift_right, swap_ranges
• Confusion over user parallelism requirements exists for these algorithms, which are likely in the above category anyway:
  • generate, generate_n
• Effective parallelism of these algorithms may be infeasible:
  • partial_sort, partial_sort_copy
• These algorithms haven't been evaluated yet. We may implement parallelism in a future release:
  • copy_if, includes, inplace_merge, lexicographical_compare, max_element, merge, min_element, minmax_element, nth_element, partition_copy, remove_copy, remove_copy_if, replace_copy, replace_copy_if, set_symmetric_difference, set_union, stable_partition, unique, unique_copy

H This is a wholly new implementation, incompatible with the previous std::experimental version, made necessary by symlink support, bug fixes, and changes in standard-required behavior. Currently, <filesystem> provides both the new std::filesystem and the previous std::experimental::filesystem. The <experimental/filesystem> header provides only the old experimental implementation. The experimental implementation will be removed in the next ABI-breaking release of the libraries.

I Supported by a compiler intrinsic.

J std::byte is enabled by /std:c++17 or later, but because it can conflict with the Windows SDK headers in some cases, it has a fine-grained opt-out macro. To disable it, define _HAS_STD_BYTE as 0.

K MSVC doesn't support the _Complex keyword or native complex types. The Universal CRT <complex.h> uses implementation-specific macros to achieve the same effect. For more information, see C complex math support.

L The Universal CRT doesn't implement the strftime E and O alternative conversion modifiers. These modifiers are ignored (for example, %Oe behaves the same as %e). The modifiers aren't supported by the underlying locale APIs.

M The Universal CRT doesn't implement C11 aligned_alloc, but does provide _aligned_malloc and _aligned_free. Because the Windows operating system doesn't support aligned allocations, this function is unlikely to be implemented.

N The declaration is removed, but the export for the function remains for backward compatibility.

O Certain bounds-checking functions are unimplemented, or have different signatures, or aren't part of the C11 or C17 standard. These functions are unimplemented: abort_handler_s, ignore_handler_s, memset_s, set_constraint_handler_s, snprintf_s, snwprintf_s, strerrorlen_s, vsnwprintf_s. These functions have different signatures: gmtime_s, localtime_s, qsort_s, strtok_s, vsnprintf_s, wcstok_s. These functions don't appear in the standard: clearerr_s, fread_s.

14 These C++17 and C++20 features are always enabled, even when /std:c++14 (the default) is specified. The reason 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.

20 In versions through Visual Studio 2019 version 16.10, these features are enabled by the /std:c++latest compiler option. When the C++20 implementation is complete, we'll add a new /std:c++20 compiler option to enable these features.

DR These features are enabled in all C++ /std compiler option modes. The C++ Standard committee adopted this change as a retroactive Defect Report to C++11 and all later versions.

C11 Compiler support for C11 and C17 requires Visual Studio 2019 version 16.8 or higher. Except as noted, C11 and C17 library support requires Windows 10 SDK build 10.0.20211.0 or higher. For more information on how to install support for C11 and C17, see Install C11 and C17 support in Visual Studio.

2104 C11 library support for this feature requires Windows 10 SDK build 10.0.20348.0 (version 2104) or higher.

See also

C++ Language Reference
C++ Standard Library
C++ conformance improvements in Visual Studio
What's New for Visual C++ in Visual Studio
Visual C++ change history 2003 through 2015
Visual C++ What's New 2003 through 2015
C++ team blog