Vylepšení shody jazyka C++, změny chování a opravy chyb v sadě Visual Studio 2022

Microsoft C/C++ v sadě Visual Studio (MSVC) vylepšuje vylepšení shody a opravy chyb v každé verzi. Tento článek uvádí významná vylepšení v hlavní verzi a potom podle verze. Pokud chcete přejít přímo na změny konkrétní verze, použijte odkazy v tomto článku .

Tento dokument obsahuje seznam změn v sadě Visual Studio 2022.

Změny v sadě Visual Studio 2019 najdete v tématu Vylepšení shody jazyka C++ v sadě Visual Studio 2019.
Změny v sadě Visual Studio 2017 najdete v tématu Vylepšení shody jazyka C++ v sadě Visual Studio 2017.
Změny ve starších verzích najdete v tématu Visual C++ Co je nového 2003 až 2015.

Vylepšení shody v sadě Visual Studio 2022 verze 17.9

Visual Studio 2022 verze 17.9 obsahuje následující vylepšení shody, opravy chyb a změny chování v kompilátoru Microsoft C/C++.

Širší souhrn změn provedených v knihovně standardní šablony najdete v tématu STL Changelog VS 2022 17.9.

Použití strukturovaného _Alignas typu v jazyce C

Ve verzích Visual C++ před sadou Visual Studio 2022 verze 17.9, když _Alignas se zobrazí vedle typu struktury v deklaraci, nebyla použita správně podle standardu ISO-C. Příklad:

// 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");

Podle standardu ISO-C by se měl tento kód zkompilovat bez static_assert generování diagnostiky. Direktiva _Alignas se vztahuje pouze na členské proměnné member1. Nesmí měnit zarovnání struct Inner. Před vydáním 17.9.1 sady Visual Studio se však vygenerovala diagnostika nesprávného zarovnání. Kompilátor zarovnaný member2 s posunem 32 bajtů uvnitř struct Outer.

Oprava této binární zásadní změny, takže když se tato změna chování použije, vygeneruje se upozornění. U předchozího kódu se upozornění C5274_Alignas " již neplatí pro typ "Inner" (platí pouze pro deklarované datové objekty)" nyní vygeneruje na úrovni upozornění 1.

V předchozích verzích sady Visual Studio byla ignorována, _Alignas když se zobrazila vedle deklarace anonymního typu. Příklad:

// 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");

Dříve se oba static_assert příkazy při kompilaci tohoto kódu nezdařily. Kód se teď zkompiluje, ale s následujícími upozorněními úrovně 1:

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)

Pokud chcete dřívější chování, nahraďte _Alignas(N) ho .__declspec(align(N)) Na rozdíl od typu declspec(align) lze použít na rozdíl od _Alignastypu.

__VA_OPT__ je povolen jako rozšíření v části /Zc:preprocessor

__VA_OPT__ byl přidán do C++20 a C23. Před jeho přidáním nebylo standardní způsob, jak variadické makro elidovat čárku. Aby byla zajištěna lepší zpětná kompatibilita, __VA_OPT__ je povolena pod preprocesorem /Zc:preprocessor založeným na tokenech ve všech jazykových verzích.

Teď se například zkompiluje bez chyby:

#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")

Jazyk C23

Pro C23 jsou při použití přepínače kompilátoru /std:clatest k dispozici následující možnosti:

typeof
typeof_unqual

Pro všechny jazykové verze jazyka C jsou k dispozici následující:

__typeof__
__typeof_unqual__

Standardní knihovna C++

Funkce C++23

Vylepšení shody v sadě Visual Studio 2022 verze 17.8

Visual Studio 2022 verze 17.8 obsahuje následující vylepšení shody, opravy chyb a změny chování v kompilátoru Microsoft C/C++.

/FU problémy s chybou

Kompilátor jazyka /FU C tuto možnost přijal, i když nějakou dobu nepodporuje spravovanou kompilaci. Teď se zobrazí chyba. Projekty, které tuto možnost předávají, musí omezit pouze na projekty C++/CLI.

Standardní knihovna C++

Pojmenované moduly std C++23 a std.compat jsou nyní k dispozici při kompilaci pomocí /std:c++20.

Širší souhrn změn provedených ve standardní knihovně C++ najdete v tématu STL Changelog VS 2022 17.8.

Vylepšení shody v sadě Visual Studio 2022 verze 17.7

Visual Studio 2022 verze 17.7 obsahuje následující zvýrazněná vylepšení shody, opravy chyb a změny chování v kompilátoru Microsoft C/C++.

Přidáno /std:clatest do kompilátoru jazyka C

Tento přepínač se chová jako /std:c++latest přepínač kompilátoru jazyka C++. Přepínač umožňuje všechny aktuálně implementované funkce kompilátoru a standardní knihovny navržené pro další verzi standardu jazyka C a také některé probíhající a experimentální funkce.

Standardní knihovna C++

Knihovna <print> je teď podporovaná. Viz P2093R14 formátovaný výstup.

Implementováno views::cartesian_product.

Širší souhrn změn provedených v knihovně standardních šablon najdete v tématu STL Changelog VS 2022 17.7.

using Shody

Dříve by direktiva using mohla způsobit, že názvy z použitých oborů názvů zůstanou viditelné, když by neměly. To může způsobit, že vyhledávání nekvalifikovaných názvů najde název v oboru názvů, i když není using žádná direktiva aktivní.

Tady je několik příkladů nového a starého chování.
Odkazy v následujících komentářích na "(1)" znamenají volání f<K>(t) v oboru názvů 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>()); 
    } 
} 

Stejný základní problém může způsobit odmítnutí kódu, který byl dříve zkompilován:

#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;
}

Vylepšení shody v sadě Visual Studio 2022 verze 17.6

Visual Studio 2022 verze 17.6 obsahuje následující vylepšení shody, opravy chyb a změny chování v kompilátoru Microsoft C/C++.

Složená volatile přiřazení už nejsou zastaralá

C++20 zastaralé použití určitých operátorů pro typy kvalifikované pomocí volatile. Například při kompilaci následujícího kódu s cl /std:c++20 /Wall test.cpp:

void f(volatile int& expr)
{
   ++expr;
}

Kompilátor vytvoří test.cpp(3): warning C5214: applying '++' to an operand with a volatile qualified type is deprecated in C++20.

V jazyce C++20 byly operátory složeného přiřazení (operátory formuláře @=) zastaralé. V jazyce C++23 už nejsou složené operátory vyloučené v jazyce C++20 zastaralé. Například v jazyce C++23 následující kód negeneruje upozornění, zatímco v jazyce C++20:

void f(volatile int& e1, int e2)
{
   e1 += e2;
}

Další informace o této změně naleznete v tématu CWG:2654

Přepis rovnosti ve výrazech je menší než zásadní změna (P2468R2)

V jazyce C++20 P2468R2 změnil kompilátor tak, aby přijímal kód, například:

struct S
{
    bool operator==(const S&);
    bool operator!=(const S&);
};
bool b = S{} != S{};

Kompilátor přijímá tento kód, což znamená, že kompilátor je přísnější s kódem, například:

struct S
{
  operator bool() const;
  bool operator==(const S&);
};

bool b = S{} == S{};

Tento program přijímá verze 17.5 kompilátoru. Verze 17.6 kompilátoru ji odmítne. Pokud ji chcete opravit, přidejte const ji, abyste operator== odstranili nejednoznačnost. Nebo přidejte odpovídající operator!= definici, jak je znázorněno v následujícím příkladu:

struct S
{
  operator bool() const;
  bool operator==(const S&);
  bool operator!=(const S&);
};

bool b = S{} == S{};

Kompilátor Microsoft C/C++ verze 17.5 a 17.6 přijímají předchozí program a volání S::operator== v obou verzích.

Obecný programovací model popsaný v P2468R2 spočívá v tom, že pokud existuje odpovídající operator!= typ, obvykle potlačí chování přepsání. Přidání odpovídající operator!= opravy je navrhovaná oprava kódu, který byl dříve zkompilován v jazyce C++17. Další informace naleznete v tématu Programovací model.

Vylepšení shody v sadě Visual Studio 2022 verze 17.4

Visual Studio 2022 verze 17.4 obsahuje následující vylepšení shody, opravy chyb a změny chování v kompilátoru Microsoft C/C++.

Základní typy bez pevného typu bez enum pevného typu

Ve verzích sady Visual Studio před sadou Visual Studio 2022 verze 17.4 kompilátor jazyka C++ neurčil správně základní typ neskopovaného výčtu bez pevného základního typu. V části /Zc:enumTypes, nyní správně implementujeme standardní chování.

Standard jazyka C++ vyžaduje, aby byl základní typ dostatečně enum velký, aby měl všechny enumerátory v daném enumobjektu . Dostatečně velké výčty mohou nastavit základní typ enumunsigned inthodnoty , long longnebo unsigned long long. Dříve tyto enum typy měly vždy základní typ int v kompilátoru Microsoftu bez ohledu na hodnoty enumerátoru.

Pokud je tato možnost povolená, /Zc:enumTypes jedná se o potenciální zdrojovou a binární zásadní změnu. Ve výchozím nastavení je vypnutý a není povolený /permissive-, protože oprava může ovlivnit binární kompatibilitu. Některé typy výčtů mění velikost, když je povolena odpovídající oprava. Některé hlavičky sady Windows SDK zahrnují takové definice výčtu.

Příklad

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
};

Typy výčtů v definici enum bez pevného podkladového typu

Ve verzích sady Visual Studio před sadou Visual Studio 2022 verze 17.4 kompilátor jazyka C++ nemodeloval správně typy výčtů. Před pravou závorkou výčtu by se mohl předpokládat nesprávný typ výčtu bez pevného podkladového typu. V části /Zc:enumTypes, kompilátor nyní správně implementuje standardní chování.

Standard jazyka C++ určuje, že v rámci definice výčtu žádného pevného základního typu inicializátory určují typy výčtů. Nebo pro enumerátory bez inicializátoru podle typu předchozího enumerátoru (účetující přetečení). Dříve byly tyto výčty vždy dány vyvolaným typem výčtu se zástupným symbolem pro základní typ (obvykle int).

Pokud je tato možnost povolená, /Zc:enumTypes jedná se o potenciální zdrojovou a binární zásadní změnu. Ve výchozím nastavení je vypnutý a není povolený /permissive-, protože oprava může ovlivnit binární kompatibilitu. Některé typy výčtů mění velikost, když je povolena odpovídající oprava. Některé hlavičky sady Windows SDK zahrnují takové definice výčtu.

Příklad

enum Enum {
    A = 'A',
    B = sizeof(A)
};

static_assert(B == 1); // previously failed, now succeeds under /Zc:enumTypes

V tomto příkladu by enumerátor A měl mít typ char před pravou složenou závorkou výčtu, takže B by měl být inicializován pomocí sizeof(char). Před opravou /Zc:enumTypesA měl typ Enum výčtu s vyvolaným základním typem inta B byl inicializován pomocí sizeof(Enum)nebo 4.

Vylepšení shody v sadě Visual Studio 2022 verze 17.3

Visual Studio 2022 verze 17.3 obsahuje následující vylepšení shody, opravy chyb a změny chování v kompilátoru Microsoft C/C++.

C: Vylepšená kontrola kompatibility modifikátoru mezi ukazateli

Kompilátor jazyka C správně nerovnal modifikátory mezi ukazateli, zejména void*. Tato chyba by mohla vést k nesprávné diagnostice nekompatibilitě mezi const int** a void* kompatibilitou mezi int* volatile* a void*.

Příklad

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
}

Vylepšení shody v sadě Visual Studio 2022 verze 17.2

Visual Studio 2022 verze 17.2 obsahuje následující vylepšení shody, opravy chyb a změny chování v kompilátoru Microsoft C/C++.

Upozornění na neusměrované obousměrné znaky

Visual Studio 2022 verze 17.2 přidává upozornění na úroveň 3 C5255 pro neukončené znaky Unicode obousměrné v komentářích a řetězcích. Toto upozornění řeší bezpečnostní problém popsaný v trojských zdrojích : Neviditelná ohrožení zabezpečení nicholase Bouchera a Rosse Andersona. Další informace o obousměrnýchch kódech Unicode naleznete v článku Standardní příloha unicode® č. 9: UNICODE BIDIRECTIONAL ALGORITHM.

Upozornění C5255 řeší pouze soubory, které po převodu obsahují obousměrné znaky Unicode. Toto upozornění platí pro soubory UTF-8, UTF-16 a UTF-32, takže musí být zadáno správné kódování zdroje. Tato změna je zásadní změnou zdroje.

Příklad (před/po)

Ve verzích sady Visual Studio před sadou Visual Studio 2022 verze 17.2 nevygeneroval neukončený obousměrný znak upozornění. Visual Studio 2022 verze 17.2 generuje upozornění 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 verze 17.2 opravuje chybu v <charconv>from_chars()float pravidlech tiebreakeru, která vytvořila nesprávné výsledky. Tato chyba ovlivnila desetinné řetězce, které byly na přesné střední bodě po sobě jdoucích float hodnot v úzkém rozsahu. (Nejmenší a největší ovlivněné hodnoty byly 32768.009765625 a 131071.98828125v uvedeném pořadí.) Pravidlo tiebreakeru chtělo zaokrouhlit na "sudé" a "sudé" bylo "dolů", ale implementace nesprávně zaokrouhlila "nahoru" (double nebyla ovlivněna.) Další informace a podrobnosti implementace najdete v tématu microsoft/STL#2366.

Tato změna má vliv na chování modulu runtime v zadaném rozsahu případů:

Příklad

// 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");
}

Ve verzích před sadou Visual Studio 2022 verze 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.

V sadě Visual Studio 2022 verze 17.2 a po:

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__ zpřístupní __STDC__ pro jazyk C

Standard jazyka C vyžaduje, aby odpovídající implementace jazyka C byla definována __STDC__ jako 1. Vzhledem k chování UCRT, který nezpřístupňuje funkce POSIX, pokud __STDC__ je 1, není možné definovat toto makro pro jazyk C ve výchozím nastavení bez zavedení zásadních změn ve stabilních jazykových verzích. Visual Studio 2022 verze 17.2 a novější přidejte možnost /Zc:__STDC__ shody, která definuje toto makro. Neexistuje žádná záporná verze možnosti. V současné době plánujeme tuto možnost používat ve výchozím nastavení pro budoucí verze jazyka C.

Tato změna je zásadní změnou zdroje. Platí, pokud je povolen režim C11 nebo C17, /std:c11 nebo /std:c17, společně s /Zc:__STDC__.

Příklad

// 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__

*/

Upozornění pro chybějící složené závorky

Upozornění C5246 hlásí chybějící složené závorky během agregované inicializace podobjektu. Před sadou Visual Studio 2022 verze 17.2 se upozornění nezpracovalo v případě anonymního struct nebo union.

Tato změna je zásadní změnou zdroje. Platí, když je povolené upozornění C5246 mimo výchozí nastavení.

Příklad

V sadě Visual Studio 2022 verze 17.2 a novější teď tento kód způsobí chybu:

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
*/

Pokud chcete tento problém vyřešit, přidejte do inicializátoru složené závorky:

void f()
{
   S s = { { 1.0f, 2.0f, 3.14f, 4.0f } };
}

Vylepšení shody v sadě Visual Studio 2022 verze 17.1

Visual Studio 2022 verze 17.1 obsahuje následující vylepšení shody, opravy chyb a změny chování v kompilátoru Microsoft C/C++.

Detekce nelokalních výrazů lambda-expression ve výchozím nastavení zachycení ve špatném formátu

Standard jazyka C++ umožňuje, aby výraz lambda v oboru bloku měl výchozí hodnotu capture. V sadě Visual Studio 2022 verze 17.1 a novější kompilátor zjistí, kdy ve výrazu lambda není povolené výchozí zachytávání. Vygeneruje nové upozornění na úroveň 4, C5253.

Tato změna je zásadní změnou zdroje. Platí v jakémkoli režimu, který používá nový procesor lambda: /Zc:lambda, /std:c++20nebo /std:c++latest.

Příklad

V sadě Visual Studio 2022 verze 17.1 teď tento kód vygeneruje chybu:

#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; };
//              ^

Pokud chcete tento problém vyřešit, odeberte výchozí zachytávání:

#pragma warning(error:5253)

auto incr = [](int value) { return value + 1; };

C4028 je teď C4133 pro operace ukazatele funkcí

Před verzí 17.1 sady Visual Studio 2022 kompilátor oznámil nesprávnou chybovou zprávu u určitých porovnání ukazatelů na funkci v kódu jazyka C. Nesprávná zpráva byla hlášena při porovnání dvou ukazatelů funkce, které měly stejné počty argumentů, ale nekompatibilní typy. Nyní vydáváme jiné upozornění, které si stěžuje na nekompatibilitu ukazatele na funkci, a ne na neshodu parametrů funkce.

Tato změna je zásadní změnou zdroje. Platí, když je kód zkompilován jako C.

Příklad

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)'

Chyba v nedependentu static_assert

Pokud výraz přidružený k static_assert závislému výrazu není v sadě Visual Studio 2022 verze 17.1 a novější, kompilátor při analýze výraz vyhodnotí. Pokud se výraz vyhodnotí jako false, kompilátor vygeneruje chybu. static_assert Pokud byl dříve v těle šablony funkce (nebo v těle členské funkce šablony třídy), kompilátor tuto analýzu neprovádí.

Tato změna je zásadní změnou zdroje. Platí v jakémkoli režimu, který znamená /permissive- nebo /Zc:static_assert. Tuto změnu chování lze zakázat pomocí možnosti kompilátoru /Zc:static_assert- .

Příklad

V sadě Visual Studio 2022 verze 17.1 a novější teď tento kód způsobí chybu:

template<typename T>
void f()
{
   static_assert(false, "BOOM!");
}

Pokud chcete tento problém vyřešit, nastavte výraz jako závislý. Příklad:

template<typename>
constexpr bool dependent_false = false;

template<typename T>
void f()
{
   static_assert(dependent_false<T>, "BOOM!");
}

Při této změně kompilátor generuje chybu pouze v případě vytvoření instance šablony f funkce.

Vylepšení shody v sadě Visual Studio 2022 verze 17.0

Visual Studio 2022 verze 17.0 obsahuje následující vylepšení shody, opravy chyb a změny chování v kompilátoru Microsoft C/C++.

Upozornění na šířku bitového pole pro typ výčtu

Když deklarujete instanci typu výčtu jako bitové pole, šířka bitového pole musí obsahovat všechny možné hodnoty výčtu. V opačném případě kompilátor vydá diagnostickou zprávu. Podívejte se na tento příklad: Zvažte:

enum class E : unsigned { Zero, One, Two };

struct S {
  E e : 1;
};

Programátor může očekávat, že člen S::e třídy může obsahovat libovolný z explicitně pojmenovaných enum hodnot. Vzhledem k počtu prvků výčtu není možné. Bitové pole nemůže pokrýt rozsah explicitně zadaných hodnot E (koncepčně doménaE). Pokud chcete vyřešit problém, že šířka bitového pole není dostatečně velká pro doménu výčtu, přidá se do MSVC nové upozornění (ve výchozím nastavení vypnuto):

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 };
                                     ^

Toto chování kompilátoru je zdrojová a binární změna způsobující chybu, která ovlivňuje všechny /std režimy a /permissive režimy.

Chyba při porovnání seřazených ukazatelů nebo nullptr 0

Standard C++ neúmyslně povolil seřazené porovnání ukazatele nebo nullptr 0. Příklad:

bool f(int *p)
{
   return p >= 0;
}

Dokument WG21 N3478 tento dohled odstranil. Tato změna se implementuje v MSVC. Při kompilaci příkladu pomocí /permissive- (a /diagnostics:caret) se vygeneruje následující chyba:

t.cpp(3,14): error C7664: '>=': ordered comparison of pointer and integer zero ('int *' and 'int')
    return p >= 0;
             ^

Toto chování kompilátoru je zdrojová a binární změna způsobující chybu, která ovlivňuje kód zkompilovaný ve /permissive- všech /std režimech.

Viz také

Shoda jazyka Microsoft C/C++