C++ Conformance improvements, behavior changes, and bug fixes in Visual Studio 2022
Microsoft C/C++ in Visual Studio (MSVC) makes conformance improvements and bug fixes in every release. This article lists the significant improvements by major release, then by version. To jump directly to the changes for a specific version, use the In this article links.
This document lists the changes in Visual Studio 2022.
For changes in Visual Studio 2019, see C++ conformance improvements in Visual Studio 2019.
For changes in Visual Studio 2017, see C++ conformance improvements in Visual Studio 2017.
For changes in older versions, see Visual C++ What's New 2003 through 2015.
Conformance improvements in Visual Studio 2022 version 17.11
Visual Studio 2022 version 17.11 has the following conformance improvements, bug fixes, and behavior changes in the Microsoft C/C++ compiler.
For an in-depth summary of changes made to the Standard Template Library, including conformance changes, bug fixes, and performance improvements, see STL Changelog VS 2022 17.11.
Print blank lines with println
Per P3142R0, it's now easy to generate a blank line with println. This feature is available when compiling with /std:c++latest.
Before this change, you wrote: println(""); Now you write: println();.
println();is equivalent toprintln(stdout);println(FILE* stream);is equivalent toprintln(stream, "\n");
Implemented range_formatter
Per P2286R8, range_formatter is now implemented. This feature is available when compiling with /std:c++latest.
Conformance improvements in Visual Studio 2022 version 17.10
Visual Studio 2022 version 17.10 has the following conformance improvements, bug fixes, and behavior changes in the Microsoft C/C++ compiler.
For an in-depth summary of changes made to the Standard Template Library, including conformance changes, bug fixes, and performance improvements, see STL Changelog VS 2022 17.10.
Conversion operator specialization with explicitly specified return type
The compiler used to specialize conversion operators incorrectly in some cases, which could lead to a mismatched return type. These invalid specializations no longer happen. This is a source code breaking change.
// Example 1
struct S
{
template<typename T> operator const T*();
};
void test()
{
S{}.operator int*(); // this is invalid now
S{}.operator const int*(); // this is valid
}
// Example 2
// In some cases, the overload resolution result may change
struct S
{
template <typename T> operator T*(); // overload 1
template <typename T> operator const T*(); // overload 2
};
void test()
{
S{}.operator int*(); // this used to call overload 2, now it calls overload 1
}
Added Support for #elifdef and #elifndef
Support added for WG21 P2334R1 (C++23) and WG14 N2645 (C++23) which introduced the #elifdef and #elifndef preprocessor directives.
Requires /std:clatest or /std:c++latest.
Before:
#ifdef __cplusplus
#include <atomic>
#elif !defined(__STDC_NO_ATOMICS__)
#include <stdatomic.h>
#else
#include <custom_atomics_library.h>
#endif
After:
#ifdef __cplusplus
#include <atomic>
#elifndef __STDC_NO_ATOMICS__
#include <stdatomic.h>
#else
#include <custom_atomics_library.h>
#endif
Application of _Alignas on a structured type in C
Applies to the C language (C17 and later). Also added to Microsoft Visual Studio 17.9
In versions of Visual C++ before Visual Studio 2022 version 17.9, if the _Alignas specifier appeared next to a structured type in a declaration, it wasn't applied correctly according to the ISO-C Standard.
// compile with /std:c17
#include <stddef.h>
struct Outer
{
_Alignas(32) struct Inner { int i; } member1;
struct Inner member2;
};
static_assert(offsetof(struct Outer, member2)==4, "incorrect alignment");
According to the ISO-C Standard, this code should compile without static_assert emitting a diagnostic.
The _Alignas directive applies only to the member variable member1. It must not change the alignment of struct Inner. However, before Visual Studio 17.9.1, the diagnostic "incorrect alignment" was emitted. The compiler aligned member2 to an offset of 32 bytes within the struct Outer type.
This is a binary breaking change, so a warning is now emitted when this change takes effect. Warning C5274 is now emitted at warning level 1 for the previous example: warning C5274: behavior change: _Alignas no longer applies to the type 'Inner' (only applies to declared data objects).
Also, in previous versions of Visual Studio, when the _Alignas specifier appeared next to an anonymous type declaration, it was ignored.
// compile with /std:c17
#include <stddef.h>
struct S
{
_Alignas(32) struct { int anon_member; };
int k;
};
static_assert(offsetof(struct S, k)==4, "incorrect offsetof");
static_assert(sizeof(struct S)==32, "incorrect size");
Previously, both static_assert statements failed when compiling this code. Now the code compiles, but emits the following level 1 warnings:
warning C5274: behavior change: _Alignas no longer applies to the type '<unnamed-tag>' (only applies to declared data objects)
warning C5273: behavior change: _Alignas on anonymous type no longer ignored (promoted members will align)
To get the previous behavior, replace _Alignas(N) with __declspec(align(N)). Unlike _Alignas, declspec(align) applies to the type.
Improved warning C4706
This is a source code breaking change. Previously, the compiler didn't detect the convention of wrapping an assignment in parentheses, if assignment was intended, to suppress warning C4706 about assignment within a conditional expression. The compiler now detects the parentheses and suppresses the warning.
#pragma warning(error: 4706)
struct S
{
auto mf()
{
if (value = 9)
return value + 4;
else
return value;
}
int value = 9;
};
The compiler now also emits the warning in cases where the function isn't referenced. Previously, because mf is an inline function that isn't referenced, warning C4706 wasn't emitted for this code. Now the warning is emitted:
error C4706: assignment used as a condition
note: if an assignment is intended you can enclose it in parentheses, '(e1 = e2)', to silence this warning
To fix this warning, either use an equality operator, value == 9, if this is what was intended. Or, wrap the assignment in parentheses, (value = 9), if assignment is intended. Otherwise, since the function is unreferenced, remove it.
Conformance improvements in Visual Studio 2022 version 17.9
Visual Studio 2022 version 17.9 contains the following conformance improvements, bug fixes, and behavior changes in the Microsoft C/C++ compiler.
For a broader summary of changes made to the Standard Template Library, see STL Changelog VS 2022 17.9.
Application of _Alignas on a structured type in C
In versions of Visual C++ before Visual Studio 2022 version 17.9, when _Alignas appeared next to a structure type in a declaration, it wasn't applied correctly according to the ISO-C Standard. For example:
// compile with /std:c17
#include <stddef.h>
struct Outer
{
_Alignas(32) struct Inner { int i; } member1;
struct Inner member2;
};
static_assert(offsetof(struct Outer, member2)==4, "incorrect alignment");
According to the ISO-C Standard, this code should compile without the static_assert emitting a diagnostic. The _Alignas directive applies only to the member variable member1. It must not change the alignment of struct Inner. However, before release 17.9.1 of Visual Studio, the diagnostic "incorrect alignment" was emitted. The compiler aligned member2 to a 32 byte offset within struct Outer.
Fixing this is a binary breaking change, so when this change in behavior is applied a warning is emitted. For the preceding code, Warning C5274, "_Alignas no longer applies to the type 'Inner' (only applies to declared data objects)" is now emitted at warning level 1.
In previous versions of Visual Studio, _Alignas was ignored when it appeared next to an anonymous type declaration. For example:
// compile with /std:c17
#include <stddef.h>
struct S {
_Alignas(32) struct { int anon_member; };
int k;
};
static_assert(offsetof(struct S, k)==4, "incorrect offsetof");
static_assert(sizeof(struct S)==32, "incorrect size");
Previously, both static_assert statements failed when compiling this code. The code now compiles, but with the following level 1 warnings:
warning C5274: behavior change: _Alignas no longer applies to the type '<unnamed-tag>' (only applies to declared data objects)
warning C5273: behavior change: _Alignas on anonymous type no longer ignored (promoted members will align)
If you want the earlier behavior, replace _Alignas(N) with __declspec(align(N)). Unlike _Alignas, declspec(align) can be applied to a type.
__VA_OPT__ is enabled as an extension under /Zc:preprocessor
__VA_OPT__ was added to C++20 and C23. Previous to its addition, there wasn't a standard way to elide a comma in a variadic macro. To provide better backward compatibility, __VA_OPT__ is enabled under the token based preprocessor /Zc:preprocessor across all language versions.
For example, this now compiles without error:
#define LOG_WRAPPER(message, ...) WRITE_LOG(__LINE__, message __VA_OPT__(, __VA_ARGS__))
// Failed to build under /std:c11, now succeeds.
LOG_WRAPPER("Log message");
LOG_WRAPPER("Log message with %s", "argument")
C23 language
For C23, the following are available when using the /std:clatest compiler switch:
The following are available for all C language versions:
C++ Standard Library
C++23 features
formattable,range_format,format_kind, andset_debug_format()as part of P2286R8 Formatting Ranges<mdspan>per P0009R18 and subsequent wording changes that were applied to the C++23 Standard.format()pointers per P2510R3.
Conformance improvements in Visual Studio 2022 version 17.8
Visual Studio 2022 version 17.8 contains the following conformance improvements, bug fixes, and behavior changes in the Microsoft C/C++ compiler.
/FU issues an error
The C compiler used to accept the /FU option, even though it hasn't support managed compilation for some time. It now issues an error. Projects that pass this option need to restrict it to C++/CLI projects only.
C++ Standard Library
The C++23 named modules std and std.compat are now available when compiling with /std:c++20.
For a broader summary of changes made to the C++ Standard Library, see STL Changelog VS 2022 17.8.
Conformance improvements in Visual Studio 2022 version 17.7
Visual Studio 2022 version 17.7 contains the following highlighted conformance improvements, bug fixes, and behavior changes in the Microsoft C/C++ compiler.
Added /std:clatest to the C compiler
This switch behaves like the /std:c++latest switch for the C++ compiler. The switch enables all currently implemented compiler and standard library features proposed for the next draft C standard, as well as some in-progress and experimental features.
C++ Standard Library
The <print> library is now supported. See P2093R14 Formatted output.
Implemented views::cartesian_product.
For a broader summary of changes made to the Standard Template Library, see STL Changelog VS 2022 17.7.
using conformance
Previously, the using directive could cause names from used namespaces to remain visible when they shouldn't. This could cause unqualified name lookup to find a name in a namespace even when there's no using directive active.
Here are some examples of the new and old behavior.
References in the following comments to "(1)" mean the call to f<K>(t) in namespace A:
namespace A
{
template<typename K, typename T>
auto f2(T t)
{
return f<K>(t); // (1) Unqualified lookup should not find anything
}
}
namespace B
{
template<typename K, typename T>
auto f(T t) noexcept
{ // Previous behavior: This function was erroneously found during unqualified lookup at (1)
return A::f2<K>(t);
}
}
namespace C
{
template<typename T>
struct S {};
template<typename, typename U>
U&& f(U&&) noexcept; // New behavior: ADL at (1) correctly finds this function
}
namespace D
{
using namespace B;
void h()
{
D::f<void>(C::S<int>());
}
}
The same underlying issue can cause code that previously compiled to now be rejected:
#include <memory>
namespace Addin {}
namespace Gui
{
using namespace Addin;
}
namespace Addin
{
using namespace std;
}
// This previously compiled, but now emits error C2065 for undeclared name 'allocator'.
// This should be declared as 'std::allocator<T*>' because the using directive nominating
// 'std' is not active at this point.
template <class T, class U = allocator<T*>>
class resource_list
{
};
namespace Gui
{
typedef resource_list<int> intlist;
}
Conformance improvements in Visual Studio 2022 version 17.6
Visual Studio 2022 version 17.6 contains the following conformance improvements, bug fixes, and behavior changes in the Microsoft C/C++ compiler.
Compound volatile assignments no longer deprecated
C++20 deprecated applying certain operators to types qualified with volatile. For example, when the following code is compiled with cl /std:c++20 /Wall test.cpp:
void f(volatile int& expr)
{
++expr;
}
The compiler produces test.cpp(3): warning C5214: applying '++' to an operand with a volatile qualified type is deprecated in C++20.
In C++20, compound assignment operators (operators of the form @=) were deprecated. In C++23, compound operators excluded in C++20 are no longer deprecated. For example, in C++23 the following code doesn't produce a warning, whereas it does in C++20:
void f(volatile int& e1, int e2)
{
e1 += e2;
}
For more information about this change, see CWG:2654
Rewriting equality in expressions is less of a breaking change (P2468R2)
In C++20, P2468R2 changed the compiler to accept code such as:
struct S
{
bool operator==(const S&);
bool operator!=(const S&);
};
bool b = S{} != S{};
The compiler accepts this code, which means that the compiler is more strict with code such as:
struct S
{
operator bool() const;
bool operator==(const S&);
};
bool b = S{} == S{};
Version 17.5 of the compiler accepts this program. Version 17.6 of the compiler rejects it. To fix it, add const to operator== to remove the ambiguity. Or, add a corresponding operator!= to the definition as shown in the following example:
struct S
{
operator bool() const;
bool operator==(const S&);
bool operator!=(const S&);
};
bool b = S{} == S{};
Microsoft C/C++ compiler versions 17.5 and 17.6 accept the previous program, and calls S::operator== in both versions.
The general programming model outlined in P2468R2 is that if there's a corresponding operator!= for a type, it typically suppresses the rewrite behavior. Adding a corresponding operator!= is the suggested fix for code that previously compiled in C++17. For more information, see Programming Model.
Conformance improvements in Visual Studio 2022 version 17.4
Visual Studio 2022 version 17.4 contains the following conformance improvements, bug fixes, and behavior changes in the Microsoft C/C++ compiler.
Underlying types of unscoped enum with no fixed type
In versions of Visual Studio before Visual Studio 2022 version 17.4, the C++ compiler didn't correctly determine the underlying type of an unscoped enumeration with no fixed base type. Under /Zc:enumTypes, we now correctly implement the standard behavior.
The C++ Standard requires the underlying type of an enum to be large enough to hold all enumerators in that enum. Sufficiently large enumerators can set the underlying type of the enum to unsigned int, long long, or unsigned long long. Previously, such enum types always had an underlying type of int in the Microsoft compiler, regardless of enumerator values.
When enabled, the /Zc:enumTypes option is a potential source and binary breaking change. It's off by default, and not enabled by /permissive-, because the fix might affect binary compatibility. Some enumeration types change size when the conformant fix is enabled. Certain Windows SDK headers include such enumeration definitions.
Example
enum Unsigned
{
A = 0xFFFFFFFF // Value 'A' does not fit in 'int'.
};
// Previously, failed this static_assert. Now passes with /Zc:enumTypes.
static_assert(std::is_same_v<std::underlying_type_t<Unsigned>, unsigned int>);
template <typename T>
void f(T x)
{
}
int main()
{
// Previously called f<int>, now calls f<unsigned int>.
f(+A);
}
// Previously this enum would have an underlying type of `int`, but Standard C++ requires this to have
// a 64-bit underlying type. Using /Zc:enumTypes changes the size of this enum from 4 to 8, which could
// impact binary compatibility with code compiled with an earlier compiler version or without the switch.
enum Changed
{
X = -1,
Y = 0xFFFFFFFF
};
Types of enumerators within an enum definition with no fixed underlying type
In versions of Visual Studio before Visual Studio 2022 version 17.4, the C++ compiler didn't correctly model the types of enumerators. It could assume an incorrect type in enumerations without a fixed underlying type before the closing brace of the enumeration. Under /Zc:enumTypes, the compiler now correctly implements the standard behavior.
The C++ Standard specifies that within an enumeration definition of no fixed underlying type, initializers determine the types of enumerators. Or, for the enumerators with no initializer, by the type of the previous enumerator (accounting for overflow). Previously, such enumerators were always given the deduced type of the enumeration, with a placeholder for the underlying type (typically int).
When enabled, the /Zc:enumTypes option is a potential source and binary breaking change. It's off by default, and not enabled by /permissive-, because the fix might affect binary compatibility. Some enumeration types change size when the conformant fix is enabled. Certain Windows SDK headers include such enumeration definitions.
Example
enum Enum {
A = 'A',
B = sizeof(A)
};
static_assert(B == 1); // previously failed, now succeeds under /Zc:enumTypes
In this example the enumerator A should have type char before the closing brace of the enumeration, so B should be initialized using sizeof(char). Before the /Zc:enumTypes fix, A had enumeration type Enum with a deduced underlying type int, and B was initialized using sizeof(Enum), or 4.
Conformance improvements in Visual Studio 2022 version 17.3
Visual Studio 2022 version 17.3 contains the following conformance improvements, bug fixes, and behavior changes in the Microsoft C/C++ compiler.
C: Improved modifier compatibility checking between pointers
The C compiler didn't properly compare modifiers between pointers, especially void*. This defect could result in an improper diagnosis of incompatibility between const int** and void* and compatibility between int* volatile* and void*.
Example
void fn(void* pv) { (pv); }
int main()
{
int t = 42;
int* pt = &t;
int* volatile * i = &pt;
fn(i); // Now raises C4090
const int** j = &pt;
fn(j); // No longer raises C4090
}
Conformance improvements in Visual Studio 2022 version 17.2
Visual Studio 2022 version 17.2 contains the following conformance improvements, bug fixes, and behavior changes in the Microsoft C/C++ compiler.
Unterminated bidirectional character warnings
Visual Studio 2022 version 17.2 adds level 3 warning C5255 for unterminated Unicode bidirectional characters in comments and strings. The warning addresses a security concern described in Trojan Source: Invisible Vulnerabilities by Nicholas Boucher and Ross Anderson. For more information on Unicode bidirectional characters, see Unicode® Standard Annex #9: UNICODE BIDIRECTIONAL ALGORITHM.
Warning C5255 only addresses files that, after conversion, contain Unicode bidirectional characters. This warning applies to UTF-8, UTF-16, and UTF-32 files, so the proper source-encoding must be provided. This change is a source breaking change.
Example (before/after)
In versions of Visual Studio before Visual Studio 2022 version 17.2, an unterminated bidirectional character didn't produce a warning. Visual Studio 2022 version 17.2 produces warning C5255:
// bidi.cpp
int main() {
const char *access_level = "user";
// The following source line contains bidirectional Unicode characters equivalent to:
// if ( strcmp(access_level, "user\u202e \u2066// Check if admin \u2069 \u2066") ) {
// In most editors, it's rendered as:
// if ( strcmp(access_level, "user") ) { // Check if admin
if ( strcmp(access_level, "user // Check if admin ") ) {
printf("You are an admin.\n");
}
return 0;
}
/* build output
bidi.cpp(8): warning C5255: unterminated bidirectional character encountered: 'U+202e'
bidi.cpp(8): warning C5255: unterminated bidirectional character encountered: 'U+2066'
*/
from_chars() float tiebreaker
Visual Studio 2022 version 17.2 fixes a bug in <charconv> from_chars() float tiebreaker rules that produced incorrect results. This bug affected decimal strings that were at the exact midpoint of consecutive float values, within a narrow range. (The smallest and largest affected values were 32768.009765625 and 131071.98828125, respectively.) The tiebreaker rule wanted to round to "even", and "even" happened to be "down", but the implementation incorrectly rounded "up" (double was unaffected.) For more information and implementation details, see microsoft/STL#2366.
This change affects runtime behavior in the specified range of cases:
Example
// from_chars_float.cpp
#include <cassert>
#include <charconv>
#include <cstdio>
#include <string_view>
#include <system_error>
using namespace std;
int main() {
const double dbl = 32768.009765625;
const auto sv = "32768.009765625"sv;
float flt = 0.0f;
const auto result = from_chars(sv.data(), sv.data() + sv.size(), flt);
assert(result.ec == errc{});
printf("from_chars() returned: %.1000g\n", flt);
printf("This rounded %s.\n", flt < dbl ? "DOWN" : "UP");
}
In versions before Visual Studio 2022 version 17.2:
C:\Temp>cl /EHsc /nologo /W4 /std:c++17 from_chars_float.cpp && from_chars_float
from_chars_float.cpp
from_chars() returned: 32768.01171875
This rounded UP.
In Visual Studio 2022 version 17.2 and after:
C:\Temp>cl /EHsc /nologo /W4 /std:c++17 from_chars_float.cpp && from_chars_float
from_chars_float.cpp
from_chars() returned: 32768.0078125
This rounded DOWN.
/Zc:__STDC__ makes __STDC__ available for C
The C standard requires that a conforming C implementation defines __STDC__ as 1. Due to the behavior of the UCRT, which doesn't expose POSIX functions when __STDC__ is 1, it isn't possible to define this macro for C by default without introducing breaking changes to the stable language versions. Visual Studio 2022 version 17.2 and later add a conformance option /Zc:__STDC__ that defines this macro. There's no negative version of the option. Currently, we plan to use this option by default for future versions of C.
This change is a source breaking change. It applies when C11 or C17 mode is enabled (/std:c11 or /std:c17) and /Zc:__STDC__ is specified.
Example
// test__STDC__.c
#include <io.h>
#include <fcntl.h>
#include <stdio.h>
int main() {
#if __STDC__
int f = _open("file.txt", _O_RDONLY);
_close(f);
#else
int f = open("file.txt", O_RDONLY);
close(f);
#endif
}
/* Command line behavior
C:\Temp>cl /EHsc /W4 /Zc:__STDC__ test__STDC__.c && test__STDC__
*/
Warning for missing braces
Warning C5246 reports missing braces during aggregate initialization of a subobject. Before Visual Studio 2022 version 17.2, the warning didn't handle the case of an anonymous struct or union.
This change is a source breaking change. It applies when the off-by-default warning C5246 is enabled.
Example
In Visual Studio 2022 version 17.2 and later, this code now causes an error:
struct S {
union {
float f[4];
double d[2];
};
};
void f()
{
S s = { 1.0f, 2.0f, 3.14f, 4.0f };
}
/* Command line behavior
cl /Wall /c t.cpp
t.cpp(10): warning C5246: 'anonymous struct or union': the initialization of a subobject should be wrapped in braces
*/
To resolve this issue, add braces to the initializer:
void f()
{
S s = { { 1.0f, 2.0f, 3.14f, 4.0f } };
}
Conformance improvements in Visual Studio 2022 version 17.1
Visual Studio 2022 version 17.1 contains the following conformance improvements, bug fixes, and behavior changes in the Microsoft C/C++ compiler.
Detect ill-formed capture default in nonlocal lambda-expressions
The C++ Standard only allows a lambda expression in block scope to have a capture-default. In Visual Studio 2022 version 17.1 and later, the compiler detects when a capture default isn't allowed in a nonlocal lambda expression. It emits a new level 4 warning, C5253.
This change is a source breaking change. It applies in any mode that uses the new lambda processor: /Zc:lambda, /std:c++20, or /std:c++latest.
Example
In Visual Studio 2022 version 17.1 this code now emits an error:
#pragma warning(error:5253)
auto incr = [=](int value) { return value + 1; };
// capture_default.cpp(3,14): error C5253: a nonlocal lambda cannot have a capture default
// auto incr = [=](int value) { return value + 1; };
// ^
To fix this issue, remove the capture default:
#pragma warning(error:5253)
auto incr = [](int value) { return value + 1; };
C4028 is now C4133 for function-to-pointer operations
Before Visual Studio 2022 version 17.1, the compiler reported an incorrect error message on certain pointer-to-function comparisons in C code. The incorrect message was reported when you compared two function pointers that had the same argument counts but incompatible types. Now, we issue a different warning that complains about pointer-to-function incompatibility rather than function parameter mismatch.
This change is a source breaking change. It applies when code is compiled as C.
Example
int f1(int);
int f2(char*);
int main(void)
{
return (f1 == f2);
}
// Old warning:
// C4028: formal parameter 1 different from declaration
// New warning:
// C4113: 'int (__cdecl *)(char *)' differs in parameter lists from 'int (__cdecl *)(int)'
Error on a nondependent static_assert
In Visual Studio 2022 version 17.1 and later, if the expression associated with a static_assert isn't a dependent expression, the compiler evaluates the expression when it's parsed. If the expression evaluates to false, the compiler emits an error. Previously, if the static_assert was within the body of a function template (or within the body of a member function of a class template), the compiler wouldn't perform this analysis.
This change is a source breaking change. It applies in any mode that implies /permissive- or /Zc:static_assert. This change in behavior can be disabled by using the /Zc:static_assert- compiler option.
Example
In Visual Studio 2022 version 17.1 and later, this code now causes an error:
template<typename T>
void f()
{
static_assert(false, "BOOM!");
}
To fix this issue, make the expression dependent. For example:
template<typename>
constexpr bool dependent_false = false;
template<typename T>
void f()
{
static_assert(dependent_false<T>, "BOOM!");
}
With this change, the compiler only emits an error if the function template f is instantiated.
Conformance improvements in Visual Studio 2022 version 17.0
Visual Studio 2022 version 17.0 contains the following conformance improvements, bug fixes, and behavior changes in the Microsoft C/C++ compiler.
Warning on bitfield width for enumeration type
When you declare an instance of an enumeration type as a bitfield, the width of the bitfield must accommodate all possible values of the enumeration. Otherwise, the compiler issues a diagnostic message. Consider this example: Consider:
enum class E : unsigned { Zero, One, Two };
struct S {
E e : 1;
};
A programmer might expect the class member S::e can hold any of the explicitly named enum values. Given the number of enumeration elements, it isn't possible. The bitfield can't cover the range of explicitly provided values of E (conceptually, the domain of E). To address the concern that the bitfield width isn't large enough for the domain of the enumeration, a new (off by default) warning is added to MSVC:
t.cpp(4,5): warning C5249: 'S::e' of type 'E' has named enumerators with values that cannot be represented in the given bit field width of '1'.
E e : 1;
^
t.cpp(1,38): note: see enumerator 'E::Two' with value '2'
enum class E : unsigned { Zero, One, Two };
^
This compiler behavior is a source and binary breaking change that affects all /std and /permissive modes.
Error on ordered pointer comparison against nullptr or 0
The C++ Standard inadvertently allowed an ordered pointer comparison against nullptr or 0. For example:
bool f(int *p)
{
return p >= 0;
}
WG21 paper N3478 removed this oversight. This change is implemented in MSVC. When the example is compiled by using /permissive- (and /diagnostics:caret), it emits the following error:
t.cpp(3,14): error C7664: '>=': ordered comparison of pointer and integer zero ('int *' and 'int')
return p >= 0;
^
This compiler behavior is a source and binary breaking change that affects code compiled using /permissive- in all /std modes.