{"id":470,"date":"2017-06-29T07:23:30","date_gmt":"2017-06-29T07:23:30","guid":{"rendered":"http:\/\/imalogic.com\/blog\/?p=470"},"modified":"2017-06-29T07:26:13","modified_gmt":"2017-06-29T07:26:13","slug":"c14-whats-important","status":"publish","type":"post","link":"https:\/\/imalogic.com\/blog\/2017\/06\/29\/c14-whats-important\/","title":{"rendered":"C++14: What’s Important"},"content":{"rendered":"

<\/p>\n

\"\"<\/a>Return type deduction<\/span><\/span><\/h4>\n

The capabilities\u00a0<\/span><\/span>auto<\/span><\/span><\/code>\u00a0are expanded in this release. C++ itself continues to be typesafe, but the mechanics of type safety are increasingly being performed by the compiler instead of the programmer.<\/span><\/span><\/p>\n

In C++11, programmers starting using\u00a0<\/span><\/span>auto<\/span><\/span><\/code>\u00a0for declarations. This was keenly appreciated for things like iterator creation, when the fully qualified type name might be horrendous. Newly minted C++ code was much easier to read:<\/span><\/span><\/p>\n

\n\n\n\n<\/colgroup>\n\n\n
<\/td>\n\n

for<\/b><\/span><\/span><\/code> (
\nauto ii = collection.begin() ; ...<\/span><\/span><\/code><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

In C++14, the use of\u00a0<\/span><\/span>auto<\/span><\/span><\/code>\u00a0is expanded in a couple of ways. One that makes perfect sense is that of\u00a0<\/span><\/span>return type deduction<\/i><\/span><\/span>. If I write a line of code like this inside a function:<\/span><\/span><\/p>\n

\n\n\n\n<\/colgroup>\n\n\n
<\/td>\n\n

return<\/b><\/span><\/span><\/code> 1.4;<\/span><\/span><\/code><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

It is obvious to both me and the compiler that the function is returning a\u00a0<\/span><\/span>double<\/span><\/span><\/code>. So in C++14, I can define the function return type as\u00a0<\/span><\/span>auto<\/span><\/span><\/code>\u00a0instead of\u00a0<\/span><\/span>double<\/span><\/span><\/code>:<\/span><\/span><\/p>\n

\n\n\n\n<\/colgroup>\n\n\n
<\/td>\n\n

auto
\ngetvalue() {<\/span><\/span><\/code><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

The\u00a0<\/span><\/span>details<\/u><\/span><\/span><\/a>\u00a0of this new feature are pretty easy to understand. For example, if a function has multiple return paths, they need to have the same type. Code like this:<\/span><\/span><\/p>\n

\n\n\n\n<\/colgroup>\n\n\n
<\/td>\n\n

auto
\nf(<\/span><\/span><\/code>int<\/b><\/span><\/span><\/code> i)<\/span><\/span><\/code><\/p>\n

{<\/span><\/span><\/code><\/p>\n

\u00a0\u00a0<\/span><\/code>if<\/b><\/span><\/span><\/code> (
\ni < 0 )<\/span><\/span><\/code><\/p>\n

\u00a0\u00a0\u00a0\u00a0<\/span><\/code>return<\/b><\/span><\/span><\/code> -1;<\/span><\/span><\/code><\/p>\n

\u00a0\u00a0<\/span><\/code>else<\/b><\/span><\/span><\/code><\/p>\n

\u00a0\u00a0\u00a0\u00a0<\/span><\/code>return<\/b><\/span><\/span><\/code> 2.0<\/span><\/span><\/code><\/p>\n

}<\/span><\/span><\/code><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

might seem like it should obviously have a deduced return type of\u00a0<\/span><\/span>double<\/span><\/span><\/code>, but the standard prohibits this ambiguity, and the compiler property complains:<\/span><\/span><\/p>\n

error_01.cpp:6:5: error: 'auto' in return type deduced as 'double' here but deduced as 'int' in<\/span>\r\n      earlier return statement<\/span>\r\n    return 2.0<\/span>\r\n    ^<\/span>\r\n1 error generated.<\/span><\/pre>\n
There several good reasons why deducing the return type is a plus for your C++ programs. First, there are times when you need to return a fairly complex type, such as an iterator, perhaps when searching into a standard library container. The\u00a0<\/span><\/span>auto<\/span><\/span><\/code>\u00a0return type makes the function easier to write properly, and easier to read. A second (maybe less obvious) reason is that using an\u00a0<\/span><\/span>auto
\n<\/span><\/span><\/code>return type enhances your ability to refactor. As an example, consider this program:<\/span><\/span><\/p>\n
\n\n\n\n<\/colgroup>\n\n\n
 
<\/td>\n\n
#include
\n<iostream><\/span><\/span><\/code><\/p>\n
#include
\n<vector><\/span><\/span><\/code><\/p>\n
#include
\n<string><\/span><\/span><\/code><\/p>\n
struct<\/b><\/span><\/span><\/code> record
\n{<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0<\/span><\/code>std::string
\nname;<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0<\/span><\/code>int<\/b><\/span><\/span><\/code> id;<\/span><\/span><\/code><\/p>\n
};<\/span><\/span><\/code><\/p>\n
auto
\nfind_id(<\/span><\/span><\/code>const<\/b><\/span><\/span><\/code> std::vector<record>
\n&people,<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span><\/code>const<\/b><\/span><\/span><\/code> std::string
\n&name)<\/span><\/span><\/code><\/p>\n
{<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>auto
\nmatch_name = [&name](<\/span><\/span><\/code>const<\/b><\/span><\/span><\/code> record&
\nr) -> <\/span><\/span><\/code>bool<\/b><\/span><\/span><\/code> {<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0\u00a0<\/span><\/code>return<\/b><\/span><\/span><\/code> r.name
\n== name;<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>};<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>auto
\nii = find_if(people.begin(), people.end(), match_name );<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>if<\/b><\/span><\/span><\/code> (ii
\n== people.end())<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0\u00a0<\/span><\/code>return<\/b><\/span><\/span><\/code> -1;<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>else<\/b><\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0\u00a0<\/span><\/code>return<\/b><\/span><\/span><\/code> ii->id;<\/span><\/span><\/code><\/p>\n
}<\/span><\/span><\/code><\/p>\n
int<\/b><\/span><\/span><\/code> main()<\/span><\/span><\/code><\/p>\n
{<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>std::vector<record>
\nroster = { {<\/span><\/span><\/code>\"mark\"<\/span><\/span><\/code>,1},<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span><\/code>{<\/span><\/span><\/code>\"bill\"<\/span><\/span><\/code>,2},<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span><\/code>{<\/span><\/span><\/code>\"ted\"<\/span><\/span><\/code>,3}};<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>std::cout
\n<< find_id(roster,<\/span><\/span><\/code>\"bill\"<\/span><\/span><\/code>)
\n<< <\/span><\/span><\/code>\"\\n\"<\/span><\/span><\/code>;<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>std::cout
\n<< find_id(roster,<\/span><\/span><\/code>\"ron\"<\/span><\/span><\/code>)
\n<< <\/span><\/span><\/code>\"\\n\"<\/span><\/span><\/code>;<\/span><\/span><\/code><\/p>\n
}<\/span><\/span><\/code><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
In this example, I\u2019m not saving many brain cells by having\u00a0<\/span><\/span>find_id()<\/span><\/span><\/code>\u00a0return\u00a0<\/span><\/span>auto<\/span><\/span><\/code>\u00a0instead of\u00a0<\/span><\/span>int<\/span><\/span><\/code>. But consider what happens if I decide that I want to refactor my\u00a0<\/span><\/span>record<\/span><\/span><\/code>\u00a0structure. Instead of using an integral type to identify the person in the\u00a0<\/span><\/span>record<\/span><\/span><\/code>\u00a0object, maybe I have a new\u00a0<\/span><\/span>GUID<\/span><\/span><\/code>\u00a0type:<\/span><\/span><\/p>\n
\n\n\n\n<\/colgroup>\n\n\n
 
<\/td>\n\n
struct<\/b><\/span><\/span><\/code> record
\n{<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0<\/span><\/code>std::string
\nname;<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0<\/span><\/code>GUID
\nid;<\/span><\/span><\/code><\/p>\n
};<\/span><\/span><\/code><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
Making that change to the\u00a0<\/span><\/span>record<\/span><\/span><\/code>\u00a0object will cause a series of cascading changes in things like the return types of functions. But if my function uses automatic return type deduction, the compiler will silently make the change for me.<\/span><\/span><\/p>\n
Generic Lambdas<\/span><\/span><\/h4>\n
Another place where\u00a0<\/span><\/span>auto<\/span><\/span><\/code>\u00a0has insinuated itself is in the definitions of lambda parameters. Defining lambda parameters with an\u00a0<\/span><\/span>auto<\/span><\/span><\/code>\u00a0type declaration is the loose equivalent of creating a template function. The lambda will be instantiated in a specific embodiment based on the deduced types of the arguments.<\/span><\/span><\/p>\n
This is convenient for creating lambdas that can be reused in different contexts. In the simple example below, I\u2019ve created a lambda used as a predicate in a standard library function. In the C++11 world, I would have needed to explicitly instantiate one lambda for adding integers, and a second for adding strings.<\/span><\/span><\/p>\n
With the addition of generic lambdas, I can define a single lambda with generic parameters. Although the syntax doesn\u2019t include the keyword\u00a0<\/span><\/span>template<\/span><\/span><\/code>, this is still clearly a further extension of C++ generic programming:<\/span><\/span><\/p>\n
\n\n\n\n<\/colgroup>\n\n\n
 
<\/td>\n\n
#include
\n<iostream><\/span><\/span><\/code><\/p>\n
#include
\n<vector><\/span><\/span><\/code><\/p>\n
#include
\n<string><\/span><\/span><\/code><\/p>\n
#include
\n<numeric><\/span><\/span><\/code><\/p>\n
int<\/b><\/span><\/span><\/code> main()<\/span><\/span><\/code><\/p>\n
{<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>std::vector<<\/span><\/span><\/code>int<\/b><\/span><\/span><\/code>>
\nivec = { 1, 2, 3, 4};<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>std::vector<std::string>
\nsvec = { <\/span><\/span><\/code>\"red\"<\/span><\/span><\/code>,<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span><\/code>\"green\"<\/span><\/span><\/code>,<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span><\/code>\"blue\"<\/span><\/span><\/code> };<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>auto
\nadder\u00a0 = [](auto op1, auto op2){ <\/span><\/span><\/code>return<\/b><\/span><\/span><\/code> op1
\n+ op2; };<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>std::cout
\n<< <\/span><\/span><\/code>\"int
\nresult : \"<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span><\/code><<
\nstd::accumulate(ivec.begin(),<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span><\/code>ivec.end(),<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span><\/code>0,<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span><\/code>adder
\n)<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span><\/code><<
\n<\/span><\/span><\/code>\"\\n\"<\/span><\/span><\/code>;<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>std::cout
\n<< <\/span><\/span><\/code>\"string
\nresult : \"<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span><\/code><<
\nstd::accumulate(svec.begin(),<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span><\/code>svec.end(),<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span><\/code>std::string(<\/span><\/span><\/code>\"\"<\/span><\/span><\/code>),<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span><\/code>adder
\n)<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span><\/code><<
\n<\/span><\/span><\/code>\"\\n\"<\/span><\/span><\/code>;<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>return<\/b><\/span><\/span><\/code> 0;<\/span><\/span><\/code><\/p>\n
}<\/span><\/span><\/code><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
Which produces the following output:<\/span><\/span><\/p>\n
\n\n\n\n<\/colgroup>\n\n\n
 
<\/td>\n\n
int<\/b><\/span><\/span><\/code> result
\n: 10<\/span><\/span><\/code><\/p>\n
string
\nresult : redgreenblue<\/span><\/span><\/code><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
Even if you are instantiating anonymous inline lambdas, employing generic parameters is still useful for the reasons I discussed earlier in this article. When your data structures change, or functions in your APIs get signature modifications, generic lambdas will adjust with recompilation instead of requiring rewrites:<\/span><\/span><\/p>\n
\n\n\n\n<\/colgroup>\n\n\n
 
<\/td>\n\n
std::cout
\n<< <\/span><\/span><\/code>\"string
\nresult : \"<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span><\/code><<
\nstd::accumulate(svec.begin(),<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span><\/code>svec.end(),<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span><\/code>std::string(<\/span><\/span><\/code>\"\"<\/span><\/span><\/code>),<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span><\/code>[](auto
\nop1,auto op2){ <\/span><\/span><\/code>return<\/b><\/span><\/span><\/code> op1+op2;
\n} )<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span><\/code><<
\n<\/span><\/span><\/code>\"\\n\"<\/span><\/span><\/code>;<\/span><\/span><\/code><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
Initialized Lambda Captures<\/span><\/span><\/h4>\n
In C++11, we had to start adjusting to the notion of a\u00a0lambda capture<\/i>\u00a0specification. That declaration guides the compiler during the creation of the\u00a0closure<\/i>: an instance of the function defined by the lambda, along with bindings to variables defined outside the lambda\u2019s scope.<\/span><\/span><\/p>\n
New, useful features that make the language safer and more convenient.<\/b>
\n<\/span><\/span><\/span><\/p>\n
In the earlier example on deduced return types, I had a lambda definition that captured a single variable,\u00a0<\/span><\/span><\/span>name<\/span><\/span><\/span><\/code>, used as the source of a search string in a predicate:<\/span><\/span><\/span><\/p>\n
\n\n\n\n<\/colgroup>\n\n\n
 
<\/td>\n\n
auto
\nmatch_name = [&name](<\/span><\/span><\/code>const<\/b><\/span><\/span><\/code> record&
\nr) -> <\/span><\/span><\/code>bool<\/b><\/span><\/span><\/code> {<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>return<\/b><\/span><\/span><\/code> r.name
\n== name;<\/span><\/span><\/code><\/p>\n
};<\/span><\/span><\/code><\/p>\n
auto
\nii = find_if(people.begin(), people.end(), match_name );<\/span><\/span><\/code><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
This particular capture gives the lambda access to the variable by reference. Captures can also be performed by value, and in both cases, the use of the variable behaves in a way that fits with C++ intuition. Capture by value means the lambda operates on a local copy of a variable; capture by reference means the lambda operates on the actual instance of the variable from the outer scope.<\/span><\/span><\/span><\/p>\n
All this is fine, but it comes with some limitations. I think the one that the committee felt it needed to address was the inability to initialize captured variables using move-only semantics.<\/span><\/span><\/span><\/p>\n
What does this mean? If we expect that lambda is going to be a\u00a0<\/span><\/span><\/span>sink<\/i><\/span><\/span><\/span>\u00a0for a parameter, we would like to capture the outer variable using move semantics. As an example, consider how you would get a lambda to sink a\u00a0<\/span><\/span><\/span>unique_ptr<\/span><\/span><\/span><\/code>, which is a move-only object. A first attempt to capture by value fails:<\/span><\/span><\/span><\/p>\n
\n\n\n\n<\/colgroup>\n\n\n
 
<\/td>\n\n
std::unique_ptr<<\/span><\/span><\/code>int<\/b><\/span><\/span><\/code>>
\np(<\/span><\/span><\/code>new<\/b><\/span><\/span><\/code> int<\/b><\/span><\/span><\/code>);<\/span><\/span><\/code><\/p>\n
*p
\n= 11;<\/span><\/span><\/code><\/p>\n
auto
\ny = [p]() { std::cout << <\/span><\/span><\/code>\"inside:
\n\"<\/span><\/span><\/code> <<
\n*p << <\/span><\/span><\/code>\"\\n\"<\/span><\/span><\/code>;};<\/span><\/span><\/code><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
This code generates a compiler error because\u00a0<\/span><\/span><\/span>unique_ptr<\/span><\/span><\/span><\/code>\u00a0does not generate a copy constructor \u2014 it specifically wants to ban making copies.<\/span><\/span><\/span><\/p>\n
Changing this so that\u00a0<\/span><\/span><\/span>p<\/span><\/span><\/span><\/code>\u00a0is captured by reference compiles fine, but it doesn\u2019t have the desired effect of sinking the value by moving the value into the local copy. Eventually, you could accomplish this by creating a local variable and calling\u00a0<\/span><\/span><\/span>std::move()<\/span><\/span><\/span><\/code>\u00a0on your captured reference, but this is a bit inefficient.<\/span><\/span><\/span><\/p>\n
The fix for this is a modification of the capture clause syntax. Now, instead of just declaring a capture variable, you can do an initialization. The simple case that is used as an example in the standard looks like this:<\/span><\/span><\/span><\/p>\n
\n\n\n\n<\/colgroup>\n\n\n
 
<\/td>\n\n
auto
\ny = [&r = x, x = x+1]()-><\/span><\/span><\/code>int<\/b><\/span><\/span><\/code> {...}<\/span><\/span><\/code><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
This captures a copy of\u00a0<\/span><\/span><\/span>x<\/span><\/span><\/span><\/code>\u00a0and increments the value simultaneously. The example is easy to understand, but I\u2019m not sure it captures the value of this new syntax for sinking move-only variables. A use case that takes advantage of this shown here:<\/span><\/span><\/span><\/p>\n
\n\n\n\n<\/colgroup>\n\n\n
 
<\/td>\n\n
#include
\n<memory><\/span><\/span><\/code><\/p>\n
#include
\n<iostream><\/span><\/span><\/code><\/p>\n
int<\/b><\/span><\/span><\/code> main()<\/span><\/span><\/code><\/p>\n
{<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>std::unique_ptr<<\/span><\/span><\/code>int<\/b><\/span><\/span><\/code>>
\np(<\/span><\/span><\/code>new<\/b><\/span><\/span><\/code> int<\/b><\/span><\/span><\/code>);<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>int<\/b><\/span><\/span><\/code> x
\n= 5;<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>*p
\n= 11;<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>auto
\ny = [p=std::move(p)]() { std::cout << <\/span><\/span><\/code>\"inside:
\n\"<\/span><\/span><\/code> <<
\n*p << <\/span><\/span><\/code>\"\\n\"<\/span><\/span><\/code>;};<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>y();<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>std::cout
\n<< <\/span><\/span><\/code>\"outside:
\n\"<\/span><\/span><\/code> <<
\n*p << <\/span><\/span><\/code>\"\\n\"<\/span><\/span><\/code>;<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>return<\/b><\/span><\/span><\/code> 0;<\/span><\/span><\/code><\/p>\n
}<\/span><\/span><\/code><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
In this case, the captured value\u00a0<\/span><\/span><\/span>p<\/span><\/span><\/span><\/code>\u00a0is initialized using move semantics, effectively sinking the pointer without the need to declare a local variable:<\/span><\/span><\/span><\/p>\n
inside: 11<\/span><\/span><\/span>\r\nSegmentation fault (core dumped)<\/span><\/span><\/span><\/pre>\n
That annoying result is what you expect \u2014 the code attempts to dereference\u00a0<\/span><\/span><\/span>p<\/span><\/span><\/span><\/code>\u00a0after it was captured and moved into the lambda.<\/span><\/span><\/span><\/p>\n
The\u00a0<\/span><\/span><\/span>[[deprecated]]<\/span><\/span><\/span><\/code>\u00a0Attribute<\/span><\/span><\/span><\/h4>\n
The first time I saw the use of the deprecated attribute in Java, I admit to a bit of language envy. Code rot is a huge problem for most programmers. (Ever been praised for deleting code? Me neither.) This new attribute provides a systematic way to attack it.<\/span><\/span><\/span><\/p>\n
Its use is convenient and simple \u2014 just place the\u00a0<\/span><\/span><\/span>[[deprecated]]<\/span><\/span><\/span><\/code>\u00a0tag in front of a declaration \u2014 which can be a class, variable, function, or a few other things. The result looks like this:<\/span><\/span><\/span><\/p>\n
\n\n\n\n<\/colgroup>\n\n\n
 
<\/td>\n\n
class<\/b><\/span><\/span><\/code><\/p>\n
[[<\/span><\/span><\/code>deprecated<\/b><\/span><\/span><\/code>]]
\nflaky {<\/span><\/span><\/code><\/p>\n
};<\/span><\/span><\/code><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
When your program uses a deprecated entity, the compiler\u2019s reaction is left up to the implementer. Clearly, most people are going to want to see some sort of warning, and also to be able to turn that warning off at will. As an example, clang 3.4 gave this warning when instantiating a deprecated class:<\/span><\/span><\/span><\/p>\n
\n\n\n\n<\/colgroup>\n\n\n
 
<\/td>\n\n
dep.cpp:14:3:
\nwarning: <\/span><\/span><\/code>'flaky'<\/span><\/span><\/code> is
\n<\/span><\/span><\/code>deprecated<\/b><\/span><\/span><\/code> [-Wdeprecated-declarations]<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>flaky
\nf;<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>^<\/span><\/span><\/code><\/p>\n
dep.cpp:3:1:
\nnote: <\/span><\/span><\/code>'flaky'<\/span><\/span><\/code> declared
\nhere<\/span><\/span><\/code><\/p>\n
flaky
\n{<\/span><\/span><\/code><\/p>\n
^<\/span><\/span><\/code><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
Note that the syntax of C++\u00a0<\/span><\/span><\/span>attribute-tokens<\/i><\/span><\/span><\/span>\u00a0might seem a bit unfamiliar. The list of attributes, including\u00a0<\/span><\/span><\/span>[[deprecated]]<\/span><\/span><\/span><\/code>, comes after keywords like\u00a0<\/span><\/span><\/span>class<\/span><\/span><\/span><\/code>\u00a0or\u00a0<\/span><\/span><\/span>enum<\/span><\/span><\/span><\/code>, and before the entity name.<\/span><\/span><\/span><\/p>\n
This tag has an alternate form that includes a message parameter. Again, it is up to the implementer to decide what to do with this message. clang 3.4 apparently ignores the message. The output from this fragment:<\/span><\/span><\/span><\/p>\n
\n\n\n\n<\/colgroup>\n\n\n
 
<\/td>\n\n
class<\/b><\/span><\/span><\/code><\/p>\n
[[<\/span><\/span><\/code>deprecated<\/b><\/span><\/span><\/code>]]
\nflaky {<\/span><\/span><\/code><\/p>\n
};<\/span><\/span><\/code><\/p>\n
\u00a0<\/span>[[<\/span><\/span><\/code>deprecated<\/b><\/span><\/span><\/code>(<\/span><\/span><\/code>\"Consider
\nusing something other than cranky\"<\/span><\/span><\/code>)]]<\/span><\/span><\/code><\/p>\n
int<\/b><\/span><\/span><\/code> cranky()<\/span><\/span><\/code><\/p>\n
{<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0<\/span><\/code>return<\/b><\/span><\/span><\/code> 0;<\/span><\/span><\/code><\/p>\n
}<\/span><\/span><\/code><\/p>\n
\u00a0<\/span>int<\/b><\/span><\/span><\/code> main()<\/span><\/span><\/code><\/p>\n
{<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>flaky
\nf;<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>return<\/b><\/span><\/span><\/code> cranky();<\/span><\/span><\/code><\/p>\n
}<\/span><\/span><\/code><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
does not contain the error message:<\/span><\/span><\/span><\/p>\n
dep.cpp:14:10: warning: 'cranky' is deprecated [-Wdeprecated-declarations]<\/span><\/span><\/span>\r\n  return cranky();<\/span><\/span><\/span>\r\n         ^<\/span><\/span><\/span>\r\ndep.cpp:6:5: note: 'cranky' declared here<\/span><\/span><\/span>\r\nint cranky()<\/span><\/span><\/span>\r\n    ^<\/span><\/span><\/span><\/pre>\n
Binary Literals and Digit Separators<\/span><\/span><\/span><\/h4>\n
These two new features aren\u2019t earth-shaking, but they do represent nice syntactic improvements. Small changes like these give us some incremental improvements in the language that improve readability, and hence, reduce bug counts.<\/span><\/span><\/span><\/p>\n
C++ programmers can now create binary literals, adding to the existing canon of decimal, hex, and the rarely used octal radices. Binary literals start with the prefix\u00a0<\/span><\/span><\/span>0b<\/span><\/span><\/span><\/code>\u00a0and are followed by binary digits.<\/span><\/span><\/span><\/p>\n
In the U.S. and UK, we are accustomed to using commas as digit separators in written numbers, as in: $1,000,000. These digit separators are there purely for the convenience of readers, providing syntactic cues that make it easier for our brains to process long strings of numbers.<\/span><\/span><\/span><\/p>\n
The committee added digit separators to C++ for exactly the same reasons. They won\u2019t affect the evaluation of a number, they are simply present to make it easier to read and write numbers through\u00a0<\/span><\/span><\/span>chunking<\/u><\/span><\/span><\/span><\/a>.<\/span><\/span><\/span><\/p>\n
What character to use for a digit separator? Virtually every punctuation character already has an idiosyncratic use in the language, so there are no obvious choices. The final election was to use the single quote character, making the million dollar value render in C++ as:\u00a0<\/span><\/span><\/span>1'000'000.00<\/span><\/span><\/span><\/code>. Remember that the separators don\u2019t have any effect on the evaluation of the constant, so this value would be identical to\u00a0<\/span><\/span><\/span>1'0'00'0'00.00<\/span><\/span><\/span><\/code>.<\/span><\/span><\/span><\/p>\n
An example combining the use of both new features:<\/span><\/span><\/span><\/p>\n
\n\n\n\n<\/colgroup>\n\n\n
 
<\/td>\n\n
#include
\n<iostream><\/span><\/span><\/code><\/p>\n
\u00a0<\/span>int<\/b><\/span><\/span><\/code> main()<\/span><\/span><\/code><\/p>\n
{<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>int<\/b><\/span><\/span><\/code> val
\n= 0b11110000;<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>std::cout
\n<< <\/span><\/span><\/code>\"Output
\nmask: \"<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span><\/code><<
\n0b1000<\/span><\/span><\/code>'0001'<\/span><\/span><\/code>1000'0000<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span><\/code><<
\n<\/span><\/span><\/code>\"\\n\"<\/span><\/span><\/code>;<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>std::cout
\n<< <\/span><\/span><\/code>\"Proposed
\nsalary: $\"<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span><\/code><<
\n300'000.00<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span><\/code><<
\n<\/span><\/span><\/code>\"\\n\"<\/span><\/span><\/code>;<\/span><\/span><\/code><\/p>\n
\u00a0\u00a0<\/span><\/code>return<\/b><\/span><\/span><\/code> 0;<\/span><\/span><\/code><\/p>\n
}<\/span><\/span><\/code><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
This program gives the unsurprising output:<\/span><\/span><\/span><\/p>\n
Output mask: 33152<\/span><\/span><\/span>\r\nProposed salary: $300000<\/span><\/span><\/span><\/pre>\n
\u00a0<\/p>\n
\u00a0<\/p>\n<\/body>","protected":false},"excerpt":{"rendered":"
Return type deduction The capabilities\u00a0auto\u00a0are expanded in this release. C++ itself continues to be typesafe, but the mechanics of type<\/p>\n","protected":false},"author":1,"featured_media":472,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[7],"tags":[],"class_list":["post-470","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-coding"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/imalogic.com\/blog\/wp-content\/uploads\/2017\/06\/cpp_logo.png?fit=360%2C405&ssl=1","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p8J21V-7A","jetpack-related-posts":[],"_links":{"self":[{"href":"https:\/\/imalogic.com\/blog\/wp-json\/wp\/v2\/posts\/470","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/imalogic.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/imalogic.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/imalogic.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/imalogic.com\/blog\/wp-json\/wp\/v2\/comments?post=470"}],"version-history":[{"count":1,"href":"https:\/\/imalogic.com\/blog\/wp-json\/wp\/v2\/posts\/470\/revisions"}],"predecessor-version":[{"id":473,"href":"https:\/\/imalogic.com\/blog\/wp-json\/wp\/v2\/posts\/470\/revisions\/473"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/imalogic.com\/blog\/wp-json\/wp\/v2\/media\/472"}],"wp:attachment":[{"href":"https:\/\/imalogic.com\/blog\/wp-json\/wp\/v2\/media?parent=470"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/imalogic.com\/blog\/wp-json\/wp\/v2\/categories?post=470"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/imalogic.com\/blog\/wp-json\/wp\/v2\/tags?post=470"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}