{"id":26461,"date":"2020-09-04T15:00:42","date_gmt":"2020-09-04T15:00:42","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/cppblog\/?p=26461"},"modified":"2020-09-08T11:22:03","modified_gmt":"2020-09-08T11:22:03","slug":"new-safety-rules-in-c-core-check","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cppblog\/new-safety-rules-in-c-core-check\/","title":{"rendered":"New safety rules in C++ Core Check"},"content":{"rendered":"

Rust and C++ are two popular systems programming languages.\u00a0<\/span>For years, the focus of C++ has been on performance.\u00a0<\/span>W<\/span>e are increasingly hearing<\/span> calls from customers and security researchers that C++ should have stronger safety guarantees in the language.<\/span>\u00a0<\/span>C++ often falls behind Rust when it comes to programming safety.\u00a0<\/span>Visual Studio 2019 version 16.7<\/span><\/a>\u00a0<\/span>contains\u00a0<\/span>four new rules\u00a0<\/span>in C++ Core Check\u00a0<\/span>to incorporate some safety features from Rust into C++<\/span>.<\/span>\u00a0<\/span>\u00a0<\/span><\/p>\n

For more detailed information<\/span>\u00a0on C++ Core Check<\/span>, please see the\u202f<\/span>C++ Core Guidelines Checker Reference\u202f<\/span><\/a>documentation.<\/span>\u00a0<\/span>If you\u2019re just getting started with native code analysis tools, take a look at our introductory\u202f<\/span>quick start for Code Analysis for C\/C++<\/span><\/a>.<\/span>\u00a0<\/span><\/p>\n

Missin<\/span>g default <\/code><\/span>label in switch statements<\/span>\u00a0<\/span><\/h2>\n

Rust’s pattern matching constructs can be used similarly to the C++ switch<\/code> statement. One way in which they differ, however, is that the Rust equivalent requires the programmer to cover all possible p<\/span>atterns being matched. This can be achieved either through writing an explicit handler for each\u00a0<\/span>pattern or<\/span>\u00a0appending a default handler for cases not explicitly covered.\u00a0<\/span>\u00a0<\/span><\/p>\n

For example, the following Rust code would not compile if the default handler\u00a0<\/span>were<\/span>\u00a0<\/span>missin<\/span>g.<\/span>\u00a0<\/span><\/p>\n

\/\/ i32 == 32-bit signed integer\u00a0\r\nfn printDiceRoll(roll: i32) {\u00a0\r\n\u00a0\u00a0\u00a0 match roll {\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 1 => println!(\"one!\"),\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2 => println!(\"two!\"),\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 3 => println!(\"three!\"),\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 4 => println!(\"four!\"),\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 5 => println!(\"five!\"),\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 6 => println!(\"six!\"),\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 _ => println!(\"what kind of dice are you using?\") \/\/ default handler\u00a0\r\n\u00a0\u00a0\u00a0 }\u00a0\r\n}<\/pre>\n
This is a neat little safety feature because it guards against this\u00a0<\/span>extremely easy<\/span>\u00a0to make, but not so easy to catch, progr<\/span>amming error.<\/span>\u00a0<\/span><\/p>\n
Visual Studio does warn whenever all cases of an <\/span>enum<\/span><\/code>\u00a0type are not covered in a C++ switch statement <C4061, C4062>. However, such a warning is not present for other types, such as integers, as in the Rust example above.<\/span>\u00a0<\/span><\/p>\n
This release\u00a0<\/span>introduces a new check to warn whenever switch statements over non-<\/span>enum<\/span> types (i.e., char<\/code>, int<\/code>, …) are missing a default<\/code> label. <\/span>You can find detailed documentation on this check <\/span>here<\/span><\/a>.\u00a0<\/span>To enable this rule in Visual Studio, you will have to select the ruleset \u201cC++ Core Check Style Rules\u201d, \u201cC++ Core Check Rules\u201d, or \u201cMicrosoft All Rules\u201d for your project and then run code analysis.<\/span>\u00a0<\/span><\/p>\n
Re-writin<\/span>g the Rust example from above in C++,\u00a0<\/span>we would<\/span>\u00a0get something like<\/span>\u00a0below.<\/span>\u00a0<\/span><\/p>\n
void printDiceRoll(int roll) {\u00a0\r\n\u00a0\u00a0\u00a0 switch (roll) {\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case 1:\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0std::cout << \"one\\n\";\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0break;\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case 2:\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0std::cout << \"two\\n\";\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0break;\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case 3:\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0std::cout << \"three\\n\";\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0break;\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case 4:\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0std::cout << \"four\\n\";\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0break;\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case 5:\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0std::cout << \"five\\n\";\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0break;\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case 6:\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0std::cout << \"six\\n\";\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0break;\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 default:\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0std::cout << \"what kind of dice are you using?\\n\";\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0break;\u00a0\r\n\u00a0\u00a0\u00a0 }\u00a0\r\n}<\/pre>\n
Removing t<\/span>he default<\/code> handler now results in a warning<\/span>.<\/span>\u00a0<\/span><\/p>\n
void printDiceRoll(int roll) {\u00a0\r\n\u00a0\u00a0\u00a0 switch (roll) { \/\/ warning C26818: Switch statement does not cover all cases. Consider adding a 'default' label (es.79)\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case 1:\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0std::cout << \"one\\n\";\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0break;\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case 2:\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0std::cout << \"two\\n\";\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0break;\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case 3:\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0std::cout << \"three\\n\";\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0break;\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case 4:\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0std::cout << \"four\\n\";\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0break;\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case 5:\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0std::cout << \"five\\n\";\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0break;\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case 6:\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0std::cout << \"six\\n\";\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0break;\u00a0\r\n\u00a0\u00a0\u00a0 }\u00a0\r\n}<\/pre>\n
Unannotated\u00a0<\/span>fallthrough<\/span>\u00a0in swit<\/span>ch statements<\/span>\u00a0<\/span><\/h2>\n
Another restriction of Rust’s match<\/code>\u00a0statement is that it does not support the notion of <\/span>fallthrough<\/span><\/code>\u00a0between cases. In C++, on the other hand, the following code is perfectly valid<\/span>.<\/span>\u00a0<\/span><\/p>\n
enum\u00a0class Food {\u00a0\r\n\u00a0\u00a0\u00a0 BANANA, ORANGE, PIZZA, CAKE, KALE, CELERY\u00a0\r\n};\u00a0\r\n\r\nvoid\u00a0takeFromFridge(Food food) {\u00a0\r\n\u00a0\u00a0\u00a0 switch (food) {\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case\u00a0Food::BANANA:\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case\u00a0Food::ORANGE:\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 peel(food);\u00a0\u00a0\u00a0\/\/ implicit\u00a0fallthrough\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case\u00a0Food::PIZZA:\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case\u00a0Food::CAKE:\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0eat(food);\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0break;\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case\u00a0Food::KALE:\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case\u00a0Food::CELERY:\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0throwOut(food);\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0break;\u00a0\r\n\u00a0\u00a0\u00a0 }\u00a0\r\n}<\/pre>\n
While this example is perfectly sound, implicit\u00a0<\/span>fallthrough<\/span>\u00a0between cases can very easily be a b<\/span>ug. Say, for instance, that the programmer of the above function had forgotten the break<\/code> statement after the call to eat(food)<\/code>. The code would run, but the behavior would be completely incorrect. With a larger and more complex codebase, tracking this t<\/span>ype of bug can be\u00a0<\/span>difficult<\/span>.<\/span>\u00a0<\/span><\/p>\n
Fortunately, with C++17 comes the addition of the [[fallthrough]] <\/span><\/span><\/span>annotation, whose purpose is to mark <\/span>fallthrough<\/span>\u00a0between case labels, such as in the example above, so that maintainers of the code can be confident th<\/span>e\u00a0<\/span>fallthrough<\/span>\u00a0behavior is intended.<\/span>\u00a0<\/span>\u00a0<\/span><\/p>\n
With Visual Studio 2019 version 16.7<\/a>, warning C26819 <\/span>is raised whenever a non-empty switch case falls through into a following case without marking the\u00a0<\/span>fallthrough<\/span> using the [[fallthrough]]<\/span><\/span><\/span>\u00a0annotation. Detailed do<\/span>cumentation can be found <\/span>here<\/span><\/a>. <\/span>This rule is enabled by default in Visual Studio<\/span>\u00a0when you run code analysis.<\/span>\u00a0<\/span><\/p>\n
void\u00a0takeFromFridge(Food food) {\u00a0\r\n\u00a0\u00a0\u00a0 switch (food) {\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case\u00a0Food::BANANA: \/\/ empty case,\u00a0fallthrough\u00a0annotation not needed\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case\u00a0Food::ORANGE:\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 peel(food);\u00a0\u00a0\u00a0\u00a0\/\/ warning C26819: Unannotated\u00a0fallthrough\u00a0between switch labels (es.78)\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case\u00a0Food::PIZZA:\u00a0 \/\/ empty case,\u00a0fallthrough\u00a0annotation not needed\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case\u00a0Food::CAKE:\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 eat(food);\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0break;\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case\u00a0Food::KALE:\u00a0 \/\/ empty case,\u00a0fallthrough\u00a0annotation not needed\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case\u00a0Food::CELERY:\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0throwOut(food);\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0break;\u00a0\r\n\u00a0\u00a0\u00a0 }\u00a0\r\n}<\/pre>\n
To fix this warning, insert a [[fallthrough]]<\/code><\/span>\u00a0statement<\/span>.<\/span><\/p>\n
void\u00a0takeFromFridge(Food food) {\u00a0\r\n\u00a0\u00a0\u00a0 switch (food) {\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case\u00a0Food::BANANA:\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case\u00a0Food::ORANGE:\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 peel(food);\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 [[fallthrough]]; \/\/ the\u00a0fallthrough\u00a0is intended\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case\u00a0Food::PIZZA:\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case\u00a0Food::CAKE:\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 eat(food);\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0break;\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case\u00a0Food::KALE:\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case\u00a0Food::CELERY:\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0throwOut(food);\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0break;\u00a0\r\n\u00a0\u00a0\u00a0 }\u00a0\r\n}<\/pre>\n
Expensive range-for copy<\/span>\u00a0<\/span><\/h2>\n
A major difference between Rust and C++ is that Rust is m<\/span>ove-by-default rather than copy-by-default.<\/span>\u00a0<\/span><\/p>\n
Some Rust code:<\/p>\n
struct MySequence {\r\n    sequence: Vec<i32>\r\n}\r\n\r\nfn main() {\r\n    let mut a = MySequence { sequence: vec![0, 1, 1, 2, 3, 5, 8, 13] };\r\n    let mut _b = a;\r\n    a.sequence.push(21); \/\/ error! `a` was move<\/span><\/span>d into `b` and can no longer be used<\/span><\/span>\r\n}<\/pre>\n
This means that explicit copy semantics must be used in most cases whenever a copy is intended.<\/span>\u00a0<\/span><\/p>\n
#[derive(Clone)]\r\nstruct MySequence {\r\n    sequence: Vec<i32>\r\n}\r\n\r\nfn main() {\r\n    let mut a = MySequence { sequence: vec![0, 1, 1, 2, 3, 5, 8, 13] };\r\n    let mut _b = a.clone();\r\n    a.sequence.push(21); \/\/ much better\r\n}<\/pre>\n
C++, on the other hand, is copy-by-default. This is not a problem in\u00a0<\/span>general but<\/span>\u00a0can sometimes be a source of bugs. One case where th<\/span>is commonly occurs is within range-for statements. Take for example the following piece of code<\/span>.<\/span>\u00a0<\/span><\/p>\n
struct Person {\u00a0\r\n\u00a0\u00a0\u00a0\u00a0std::string\u00a0first_name;\u00a0\r\n\u00a0\u00a0\u00a0\u00a0std::string\u00a0last_name;\u00a0\r\n\u00a0\u00a0\u00a0\u00a0std::string\u00a0email_address;\u00a0\r\n};\u00a0\r\n\r\nvoid\u00a0emailEveryoneInCompany(const std::vector<Person>& employees) {\u00a0\r\n\u00a0\u00a0\u00a0 Email\u00a0email;\u00a0\r\n\u00a0\u00a0\u00a0 for (Person p: employees)\u00a0{ \/\/ copy of type `Person` occurs on each iteration\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0email.addRecipient(p.email_address);\u00a0\r\n\u00a0\u00a0\u00a0 }\u00a0\r\n\u00a0\u00a0\u00a0\u00a0email.addBody(\"Sorry for the spam\");\u00a0\r\n\u00a0\u00a0\u00a0\u00a0email.send();\u00a0\r\n}<\/pre>\n
In the above snippet, each element of the vector is copied into p<\/code> on each iteration of the loop. This is not obvious and can be a significant source of inefficiency if the copy is expensive. To remedy this unnecessary copy, <\/span>we added\u00a0<\/span>a new\u00a0<\/span>C++ Core Check rule<\/span>, suggesting a way to remove the copy<\/span>.<\/span>\u00a0<\/span><\/p>\n
void\u00a0emailEveryoneInCompany(const std::vector<Person>& employees) {\u00a0\r\n\u00a0\u00a0\u00a0 Email\u00a0email;\u00a0\r\n\u00a0\u00a0\u00a0 for (Person p: employees)\u00a0{ \/\/ Warning C26817: Potentially expensive copy of variable 'p' in range-for loop. Consider making it a const reference (es.71)\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0email.addRecipient(p.email_address);\u00a0\r\n\u00a0\u00a0\u00a0 }\u00a0\r\n\u00a0\u00a0\u00a0\u00a0email.addBody(\"Sorry for the spam\");\u00a0\r\n\u00a0\u00a0\u00a0\u00a0email.send();\u00a0\r\n}<\/pre>\n
By using the suggestion from the warning and changing the type of the variable p<\/code> in the<\/span> loop from a Person<\/code> to a const Person&<\/code>, the variable no longer receives an expensive copy of the data on each iteration.<\/span>\u00a0<\/span><\/p>\n
void\u00a0emailEveryoneInCompany(const std::vector<Person>& employees) {\u00a0\r\n\u00a0\u00a0\u00a0 Email\u00a0email;\u00a0\r\n\u00a0\u00a0\u00a0 for (const Person& p: employees)\u00a0{ \/\/ expensive copy no longer occurs\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0email.addRecipient(p.email_address);\u00a0\r\n\u00a0\u00a0\u00a0 }\u00a0\r\n\u00a0\u00a0\u00a0\u00a0email.addBody(\"Sorry for the spam\");\u00a0\r\n\u00a0\u00a0\u00a0\u00a0email.send();\u00a0\r\n}<\/pre>\n
To decide what constitutes an “expensive” copy, the following heuristic is used by the che<\/span>ck:<\/span>\u00a0<\/span><\/p>\n
If the size of the type is greater than twice the platform-dependent pointer size and the type is not a smart pointer or one of <\/span>gsl<\/span><\/code>::span<\/code>, <\/span>gsl<\/span>::<\/span>string_span<\/span><\/code>, or std::<\/code><\/span>string_view<\/span><\/code>, then the copy is considered expensive. This means that for small\u00a0<\/span>datatypes<\/span> such as numeric scalars, the warning will not trigger. For larger types, such as the Person<\/code> type in the example above, the copy is considered expensive and a warning will be raised.<\/span>\u00a0<\/span><\/p>\n
One final point to note is that the check will not fire if t<\/span>he variable is mutated in the loop body<\/span>.<\/span>\u00a0<\/span><\/p>\n
struct Person {\u00a0\r\n\u00a0\u00a0\u00a0\u00a0std::string\u00a0first_name;\u00a0\r\n\u00a0\u00a0\u00a0\u00a0std::string\u00a0last_name;\u00a0\r\n\u00a0\u00a0\u00a0 int\u00a0hourlyrate; \/\/ dollars per hour\u00a0\r\n};\u00a0\r\n\r\nvoid\u00a0giveEveryoneARaise(const std::vector<Person>& employees) {\u00a0\r\n\u00a0\u00a0\u00a0 for (Person p: employees) {\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0p.hourlyrate\u00a0+= 10; \/\/ `p` can no longer be marked `const Person&`, so the copy is unavoidable\u00a0\r\n\u00a0\u00a0\u00a0 }\u00a0\r\n}<\/pre>\n
If instead the container\u00a0<\/span>was not<\/span> const-qualified, then the copy could be avoided by changing the type Person<\/code> to Perso<\/code><\/span>n&<\/code>.<\/span>\u00a0<\/span><\/p>\n
void\u00a0giveEveryoneARaise() {\u00a0\r\n\u00a0\u00a0\u00a0\u00a0std::vector<Person> employees =\u00a0getEmployees();\u00a0\r\n\u00a0\u00a0\u00a0 for (Person& p: employees)\u00a0{ \/\/ no more expensive copying, but any subsequent mutation will change the container!\u00a0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0p.hourlyrate\u00a0+= 10;\u00a0\r\n\u00a0\u00a0\u00a0 }\u00a0\r\n}<\/pre>\n
But this change comes with the introduction of new side-effects to the code. Therefore, the range-for copy warning only ever suggests\u00a0<\/span>marking<\/span> the loop variable as const T&<\/code><\/span>, and<\/span> will not fire if the loop-variable cannot legally be marked const<\/code>.<\/span>\u00a0<\/span><\/p>\n
Full documentation of the check can be found here<\/a><\/span>.\u00a0<\/span>This rule is enabled by default in Visual Studio<\/span>\u00a0when you run code analysis.<\/span>\u00a0<\/span><\/p>\n
Expensive copy with the auto<\/code> keyword<\/span>\u00a0<\/span><\/h2>\n
The last new check in this release concerns itself with expensive copies\u00a0<\/span>occurring<\/span>\u00a0wit<\/span>h the use of the auto<\/code> type.<\/span>\u00a0<\/span><\/p>\n
Consider the following Rust example in which type resolution occurs for a variable being assigned a reference.<\/span>\u00a0<\/span><\/p>\n
struct\u00a0PasswordManager\u00a0{\u00a0\r\n\u00a0\u00a0\u00a0 password: String\u00a0\r\n}\u00a0\r\n\r\nimpl\u00a0PasswordManager\u00a0{\u00a0\r\n\u00a0\u00a0\u00a0 \/\/ member-access function returning an immutable reference to a member\u00a0\r\n\u00a0\u00a0\u00a0\u00a0fn\u00a0getPassword(&self) -> &String\u00a0{ &self.password\u00a0}\u00a0\r\n\u00a0\u00a0\u00a0 \/\/ Note: for the sake of an example dealing with expensive types, a &String is being returned.\u00a0\r\n\u00a0\u00a0\u00a0 \/\/ More realistically though, a string slice\u00a0would be returned instead (similar to\u00a0a string view in C++)\u00a0\r\n}\u00a0\r\n\r\nfn\u00a0stealPassword(pm: &PasswordManager) {\u00a0\r\n\u00a0\u00a0\u00a0 let password =\u00a0pm.getPassword(); \/\/ the type of `a` resolves to `&String`. No copy occurs.\u00a0\r\n}<\/pre>\n
Because of Rust’s requirement that in\u00a0<\/span>the<\/span>\u00a0majority of<\/span>\u00a0<\/span>cases<\/span> copying must be explicit, the type of password<\/code>\u00a0in the example automatically resolves to an immutable reference when being assigned an immutable reference, and no expensive copying is performed.<\/span>\u00a0<\/span><\/p>\n
On the other hand, consider the equiv<\/span>alent C++ code<\/span>.<\/span>\u00a0<\/span><\/p>\n
class PasswordManager {\u00a0\r\n\u00a0\u00a0\u00a0\u00a0std::string password;\u00a0\r\npublic:\u00a0\r\n\u00a0\u00a0\u00a0 const std::string& getPassword() const { return password; }\u00a0\u00a0\r\n};\u00a0\r\n\r\nvoid stealPassword(const PasswordManager& pm) {\r\n\u00a0\u00a0\u00a0 auto password = pm.getPassword(); \/\/ the type of `password` resolves to `std::string`. Copy occurs.\r\n}<\/pre>\n
Here, the type of password<\/code> resolves to <\/span>std::<\/span><\/code>string<\/code>, even though the return type of <\/span>getPassword<\/span><\/code>()<\/code> is a\u00a0<\/span>const-reference<\/span> to a string. The resulting behavior is that the contents of <\/span>Pas<\/span>swordManager<\/span>::<\/span><\/code>password<\/code> get copied into the local variable password<\/code>.<\/span><\/p>\n
Compare this with a function returning a pointer:<\/span>\u00a0<\/span><\/p>\n
class\u00a0PasswordManager\u00a0{\r\n\u00a0\u00a0\u00a0\u00a0std::string password;\r\npublic:\r\n\u00a0\u00a0\u00a0 const\u00a0std::string*\u00a0getPassword() const { return &password; }\r\n};\r\n\r\nvoid\u00a0stealPassword(const\u00a0PasswordManager& pm) {\r\n\u00a0\u00a0\u00a0 auto password =\u00a0pm.getPassword(); \/\/ the type of `password` resolves to `const std::string*`. No copy occurs.\r\n}<\/pre>\n
This difference in behavior between assigning a reference and a point<\/span>er to a variable marked auto<\/code> is non-obvious, resulting in potentially unwanted and unexpected copying.<\/span>\u00a0<\/span><\/p>\n
To guard against bugs arising from this behavior, the checker examines all instances of initialization from a reference to a variable marked auto<\/code>.<\/span> If the resulting copy is deemed expensive using the same heuristics as in the range-for check, the checker warns to mark the variable const auto&<\/code> instead.<\/span><\/p>\n
class\u00a0PasswordManager\u00a0{\r\n\u00a0\u00a0\u00a0\u00a0std::string password;\r\npublic:\r\n\u00a0\u00a0\u00a0 const\u00a0std::string&\u00a0getPassword() const { return password; }\r\n};\r\n\r\nvoid\u00a0stealPassword(const\u00a0PasswordManager& pm) {\r\n\u00a0\u00a0\u00a0 auto password =\u00a0pm.getPassword();\u00a0 \/\/ Warning C26820: Assigning by value when a const-reference would suffice, use const\u00a0auto&amp; instead (p.9)\r\n}<\/pre>\n
A<\/span>nd as with the range-for check, this warning does not get raised whenever the variable cannot be legally marked const<\/code><\/span>.<\/span>\u00a0<\/span><\/p>\n
std::string\u00a0hashPassword(const\u00a0PasswordManager& pm) {\r\n\u00a0\u00a0\u00a0 auto password =\u00a0pm.getPassword(); \/\/ warning no longer gets raised because `password` is modified below\r\n\u00a0\u00a0\u00a0 password += \"salt\";\r\n\u00a0\u00a0\u00a0 return\u00a0std::hash(password);\r\n}<\/pre>\n
Another instance in which the warning does not get raised is whenever the reference is being derived from a temporary. In such cases, using const a<\/code><\/span>uto&<\/code> would<\/span>\u00a0<\/span>result in a dangling reference once the temporary gets destroyed.<\/span>\u00a0<\/span><\/p>\n
class\u00a0PasswordManager\u00a0{\r\n\u00a0\u00a0\u00a0\u00a0std::string password;\r\npublic:\r\n\u00a0\u00a0\u00a0\u00a0PasswordManager(const std::string& password): password(password) {}\r\n\u00a0\u00a0\u00a0 const\u00a0std::string&\u00a0getPassword() const { return password; }\r\n};\r\n\r\nvoid\u00a0stealPassword() {\r\n\u00a0\u00a0\u00a0 const auto& password =\u00a0PasswordManager(\"123\").getPassword(); \/\/ using `const auto&` instead of just `auto`\r\n\u00a0\u00a0\u00a0\u00a0use_password(password); \/\/ `password` is now referencing invalid memory!\r\n}<\/pre>\n
Full documentation of the check can be found here<\/a><\/span>.\u00a0<\/span>This rule is enabled by default in Visual Studio<\/span>\u00a0when you run code analysis.<\/span><\/p>\n
Give us your feedback<\/span><\/h2>\n
Check out these newly added rules and the recently released\u00a0<\/span>GSL 3.0<\/span><\/a>\u00a0<\/span>library\u00a0<\/span>and let us know if they\u00a0<\/span>help<\/span> you write safer C++. Stay tuned as we add more safety <\/span>rules<\/span>\u00a0in future releases of Visual Studio.<\/span><\/p>\n
Download\u202f<\/span>Visual Studio 2019 version 16.7<\/span><\/a>\u00a0<\/span>today and give it a try.\u00a0<\/span>We would<\/span>\u00a0love to hear from you to help us prioritize and build the right features for you. We can be reached via the comments below,\u202f<\/span>Developer Community<\/span><\/a>,\u202fand Twitter (<\/span>@VisualC<\/span><\/a>). The best way to file a bug or suggest a feature is via Developer Community.<\/span>\u00a0<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"
Rust and C++ are two popular systems programming languages.\u00a0For years, the focus of C++ has been on performance.\u00a0We are increasingly hearing calls from customers and security researchers that C++ should have stronger safety guarantees in the language.\u00a0C++ often falls behind Rust when it comes to programming safety.\u00a0Visual Studio 2019 version 16.7\u00a0contains\u00a0four new rules\u00a0in C++ Core […]<\/p>\n","protected":false},"author":17037,"featured_media":35994,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[119,245,163],"class_list":["post-26461","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cplusplus","tag-code-analysis","tag-cppcorecheck","tag-static-analysis"],"acf":[],"blog_post_summary":"
Rust and C++ are two popular systems programming languages.\u00a0For years, the focus of C++ has been on performance.\u00a0We are increasingly hearing calls from customers and security researchers that C++ should have stronger safety guarantees in the language.\u00a0C++ often falls behind Rust when it comes to programming safety.\u00a0Visual Studio 2019 version 16.7\u00a0contains\u00a0four new rules\u00a0in C++ Core […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/26461","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/users\/17037"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/comments?post=26461"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/26461\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media\/35994"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media?parent=26461"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/categories?post=26461"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/tags?post=26461"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}