This first problem highlights the importance of understanding what you write. Here we have a few simple lines of code—most of which mean something different from all the others, even though the syntax varies only slightly.

 

Problem

JG Question

1. What is the difference, if any, among the following?

widget w;                   // (a)

widget w();                 // (b)
widget w{};                 // (c)

widget w(x);                // (d)
widget w{x};                // (e)

widget w = x;               // (f)
widget w = {x};             // (g)

auto w = x;                 // (h)
auto w = widget{x};         // (i)

Guru Questions

2. What do each of the following lines do?

vector<int> v1( 10, 20 );   // (a)

vector<int> v2{ 10, 20 };   // (b)

3. Besides the cases above, what other benefits are there to using { } to initialize objects?

4. When should you use ( ) vs. { } syntax to initialize objects? Why?

 

Solution

This puzzle demonstrates several things:

• The difference between default initialization, direct initialization, copy initialization, and list initialization.
• The difference between using ( ) and using { } for initialization.
• A red herring that isn’t initialization at all, and which modern C++ entirely avoids.

But, most important of all: If you stick to two simple Guidelines, which we’ll cover in #4, you can ignore most of these cases and the rules are pretty simple and deliver efficient performance by default.

 

1. What is the difference, if any, among the following?

Let’s consider the cases one by one.

(a) is default initialization.

widget w;                   // (a)

This code declares a variable named w, of type widget. For most types, it is initialized using the default constructor widget::widget().

Note that w is not initialized and contains garbage values if widget happens to be a built-in type like int, or a simple “int-like” class type with what’s called a “trivial” default constructor—a type that relies on the compiler-generated default constructor, has no virtual functions or virtual base classes or data member initializers, and all its bases and members satisfy the same restrictions.

(b) is a “vexing” red herring, now mostly a historical curiosity.

widget w();                 // (b)

This is a pre-modern C++ pitfall: At first glance, it may look like just another variable declaration calling a default constructor widget::widget(); in reality, thanks to a grammar ambiguity, it’s a function declaration for a function named w that takes no parameters and returns a widget object by value. (If you can’t see this at first, consider that the above code is no different from writing something like int f(); which is clearly a function declaration.)

Lest you think “aw, but those ( ) parentheses are redundant, it’s the programmer’s own fault for not just writing widget w; there!”, note that the same problem arises in those occasional cases where you think you’re initializing a variable with temporary objects:

// same problem (gadget and doodad are types)
//
widget w( gadget(), doodad() );  // pitfall: not a variable declaration

Scott Meyers long ago named this “C++’s most vexing parse,” because the standard resolves the parsing ambiguity by saying: “if it can be a function declaration, it is.”

The good news is that this is now mostly a historical curiosity, not something you should encounter in new code, because C++11 removed this pitfall. Note that C++11 does not change the meaning of the code—C++11 has great backward compatibility with C++98, including that this ambiguity still has the same meaning it always had. Rather, C++11 solves this by providing a syntax that supersedes case (b) in nearly all cases, so that we don’t need to ever fall into this pit anymore:

(c) is non-vexing and clear.

widget w{};                 // (c)

Here we have the first reason to prefer { } to ( ): For any class type widget, line (c) does the “best parts” of (a) and (b)—it always initializes the variable, and is never ambiguous with a function declaration. No vex, no fuss, no muss.

“Aha, but wait, it’s not that simple!” someone might object. “What if widget has a constructor that takes a std::initializer_list? Those are greedy (preferred), so if widget has one of those wouldn’t this call that?”

The answer is no, this really is just as simple as it looks, because the standard is explicit that an empty { } list means to call the default constructor if available. However, it’s good to be aware of initializer_lists, so let’s talk about those next.

(d) and (e) are direct initialization.

Now let’s consider cases where we actually initialize w from some existing variable:

widget w(x);                // (d)
widget w{x};                // (e)

Assuming x is not the name of a type, these are both direct initialization. That’s because the variable w is initialized “directly” from the value of x by calling widget::widget(x). If x is also of type widget, this invokes the copy constructor. Otherwise, it invokes a converting constructor.

However, note that the syntax {x} creates an initializer_list. If widget has a constructor that takes an initializer_list, that constructor is preferred; otherwise, if widget has a constructor that takes whatever type x is (possibly with conversions), that constructor is used.

There are two major differences that make (e) superior to (d): First, like (c), syntax (e) is unambiguous and avoids the vexing parse. If x is a type name, then (d) is a function declaration even if there is also a variable named x in scope (see above), whereas (e) is never a function declaration.

Second, syntax (e) is safer because it does not allow narrowing (a.k.a. “lossy”) conversions that are otherwise allowed for some built-in types. Consider:

int i1( 12.345 );           // ok: toss .345, we didn't like it anyway
int i2{ 12.345 };           // error: would be lossy implicit narrowing

(f) and (g) are copy initialization and copy list initialization.

This brings us to our final two non-auto cases:

widget w = x;               // (f)

This is called “copy initialization.” Conceptually, the variable w is initialized using widget‘s move or copy constructor, possibly after calling another function to convert the argument implicitly (explicit conversions won’t be invoked here).

Common Mistake: This is always initialization; it is never assignment, and so it never calls T::operator=(). Yes, I know there’s an “=” character in there, but don’t let that throw you — that’s just a syntax holdover from C, not an assignment operation.

Here are the semantics:

• If x is of type widget, line (f) means the same as (d) widget w(x); except that explicit constructors cannot be used. It’s guaranteed that only a single constructor is called.
• If x is of some other type, conceptually the compiler first implicitly converts x to a temporary widget object, then move-constructs w from that temporary rvalue, using copy construction as “the slow way to move” as a backup if no better move constructor is available. Assuming that an implicit conversion is available, (f) means the same as widget w( widget(x) );.

Note that I said “conceptually” a few times above. That’s because practically compilers are allowed to, and routinely do, optimize away the temporary and, if an implicit conversion is available, convert (f) to (d), thus optimizing away the extra move operation. However, even when the compiler does this, the widget copy constructor must still be accessible, even if is not called—the copy constructor’s side effects may or may not happen, that’s all.

Now note the related syntax that adds “=“:

widget w = {x};             // (g)

This is called “copy list initialization.” It means the same as widget w{x}; except that explicit constructors cannot be used. It’s guaranteed that only a single constructor is called.

(h) and (i) are also copy initialization, but simpler.

auto w = x;                 // (h)
auto w = widget{x};         // (i)

The semantics are just like (f) and (g), except simpler to teach, learn, and use because using auto guarantees the right-hand expression’s type will be deduced exactly. Note that the (i) syntax works fine for both implicit and explicit conversions.

Line (h) means the same as (d), type_of_x w(x);. Only a single copy constructor is called. This is guaranteed to stay true as the program evolves: Because line (h) does not commit to an explicit type, it is guaranteed to be both maximally efficient because there can be no conversion involved, and maximally robust under maintenance as the type of w “auto”-matically tracks the type of x which may change as the program is maintained.

Line (i) is the most consistent spelling when you do want to commit to a specific type and explicitly request a conversion if needed, and once again the { } syntax happily avoids lossy narrowing conversions. In practice on most compilers, only a single constructor is called—similarly to what we saw with (f) and (g), conceptually there are two constructor calls, a converting or copy constructor to create a temporary widget{x} followed by a move to move it to w, but compilers routinely elide the latter.

In general, I recommend that you try out these two forms, and increasingly prefer using them as you grow comfortable with them. I’m at the point where I’m now inclined to write virtually all of my local variable declarations this way. (I know some of you will be skeptical about this broad claim—more on “the auto question” in another GotW.)

 

2. What do each of the following lines do?

In the Question 2 code, we’re creating a vector<int> and passing the arguments 10 and 20 to its constructor—in the first case as ( 10, 20 ) and in the second case as { 10, 20 }.

Both will call a constructor, but which one(s)? Well, vector<int> has several constructors that can take two parameters, but only two could be correctly called with the parameters 10 and 20. Ignoring defaulted optional allocator parameters for simplicity, the two constructors are:

vector( size_t n, const int& value );    // A: n copies of value

vector( initializer_list<int> values );  // B: copy of values

There are two simple C++ rules that tell us which one will be called for the code in question:

• The syntax { /*…*/ } used in an expression context gives you an initializer_list.
• Constructors that take an initializer_list are preferred over other constructors, and so can hide other constructors that might otherwise be viable.

Armed with those two tidbits, the answer is simple:

vector<int> v1( 10, 20 );    // (a) calls A: 10 copies of the value 20
assert( v1.size() == 10 );

vector<int> v2{ 10, 20 };    // (b) calls B: the values 10 and 20
assert( v2.size() == 2 );

 

3. Besides the cases above, what other benefits are there to using { } to initialize objects?

For one thing, it’s called “uniform initialization” because it’s, well, uniform—the same for all types, including aggregate structs and arrays and std:: containers, and without the “vexing parse” annoyance:

struct mystruct { int x, y; };

// C++98 
rectangle       w( origin(), extents() );       // oops, vexing parse 
complex<double> c( 2.71828, 3.14159 ); 
mystruct        m = { 1, 2 };
int             a[] = { 1, 2, 3, 4 };
vector<int>     v;                              // urk, need more code
for( int i = 1; i <= 4; ++i ) v.push_back(i);   //   to initialize this

// C++11 (note: "=" is mostly optional)
rectangle       w   = { origin(), extents() }; 
complex<double> c   = { 2.71828, 3.14159 }; 
mystruct        m   = { 1, 2 }; 
int             a[] = { 1, 2, 3, 4 };
vector<int>     v   = { 1, 2, 3, 4 };

And note that this isn’t just an aesthetic issue. Consider writing generic code that should be able to initialize any type… and while we’re at it, let’s gratuitously use perfect forwarding as an example:

template<typename T, typename ...Args>
void forwarder( Args&&... args ) {
    // ...
    T local = { std::forward<Args>(args)... };
    // ...
}

forwarder<int>            ( 42 );                  // ok
forwarder<rectangle>      ( origin(), extents() ); // ok
forwarder<complex<double>>( 2.71828, 3.14159 );    // ok
forwarder<mystruct>       ( 1, 2 );                // ok because of {}
forwarder<int[]>          ( 1, 2, 3, 4 );          // ok because of {}
forwarder<vector<int>>    ( 1, 2, 3, 4 );          // ok because of {}

The last three lines would not be legal if forwarder used ( ) initialization syntax internally.

The new { } syntax works pretty much everywhere, including to initialize members:

widget::widget( /*...*/ ) : mem1{init1}, mem2{init2, init3} { /*...*/ } 

And, as icing on the take, it’s often just plain convenient to pass function arguments, or return a value, without a type-named temporary:

void draw_rect( rectangle ); 

draw_rect( rectangle(origin, selection) );         // C++98
draw_rect({ origin, selection });                  // C++11

rectangle compute_rect() {
   // ...
   if(cpp98) return rectangle(origin, selection);  // C++98
   else      return {origin, selection};           // C++11
}

 

4. When should you use ( ) vs. { } syntax to initialize objects? Why?

Here’s the simple guideline:

Guideline: Prefer to use initialization with { }, such as vector<int> v = { 1, 2, 3, 4 }; or auto v = vector<int>{ 1, 2, 3, 4 };, because it’s more consistent, more correct, and avoids having to know about old-style pitfalls at all. In single-argument cases where you prefer to see only the = sign, such as int i = 42; and auto x = anything; omitting the braces is fine. …

That covers the vast majority of cases. There is only one main exception:

… In rare cases, such as vector<int> v(10,20); or auto v = vector<int>(10,20);, use initialization with ( ) to explicitly call a constructor that is otherwise hidden by an initializer_list constructor.

However, the reason this should be generally “rare” is because default and copy construction are already special and work fine with { }, and good class design now mostly avoids the resort-to-( ) case for user-defined constructors because of this final design guideline:

Guideline: When you design a class, avoid providing a constructor that ambiguously overloads with an initializer_list constructor, so that users won’t need to use ( ) to reach such a hidden constructor.

 

Acknowledgments

Thanks in particular to the following for their feedback to improve this article: Michal Mocny, Jay Miller, “Alexey,” “praetorian20,” Francisco Lopes, “Neil,” Daryle Walker.

This first problem highlights the importance of understanding what you write. Here we have a few simple lines of code — most of which mean something different from all the others, even though the syntax varies only slightly.

 

Problem

JG Question

1. What is the difference, if any, among the following?

widget w;                   // (a)

widget w();                 // (b)
widget w{};                 // (c)

widget w(x);                // (d)
widget w{x};                // (e)

widget w = x;               // (f)
widget w = {x};             // (g)

auto w = x;                 // (h)
auto w = widget{x};         // (i)

Guru Questions

2. What do each of the following lines do?

vector<int> v1( 10, 20 );   // (a)

vector<int> v2{ 10, 20 };   // (b)

3. Besides the cases above, what other benefits are there to using { } to initialize objects?

4. When should you use ( ) vs. { } syntax to initialize objects? Why?

It’s time for me to pick up Guru of the Week (GotW) again in earnest, as part of work on revising my three Exceptional C++ books for today’s C++. Most Exceptional C++ Items are enhanced versions of GotW issues, after all, so the simplest and best place to start is with GotW. It’s also much easier to write (and read) one short piece at a time.

Last spring I wrote a few GotWs, but life got busy with the Standard C++ Foundation, isocpp.org, and C++14. I was also trying to figure out what reasonable tools to use to write new Items, since I wanted to publish the same Item on this blog and then in e-book and dead tree editions, all with a single source while maintaining a pleasing format. I’ve found a provisional promising tool (Word!) and format for that I’ll try out for now, and you’ll see it in the next GotW issue to be posted soon.

But a major issue was figuring out the right balance between updating existing GotW issues and writing new ones.

Here’s where I landed…

 

First, I’ve decided to keep and revise nearly all of my existing Items. This is not an obvious choice: As a counterexample, some authors have decided to not revise their existing books, but to write new books about C++11, for various reasons including that they expect the advice in the earlier books is still current. I think the latter is partly true, because of course the topics are still current and the code still compiles – C++11 has a great backward compatibility story with C++98.

However, when I looked through my own articles and Items, every single one I looked at had two qualities:

• The topic was still current and useful, so it should still be covered. (With very rare exceptions like material discussing the now-removed export template feature.)
• The code and discussion were addressed with C++98-era advice that is now dated and/or incomplete.

For example, nearly every GotW’s code should just naturally use auto and { } initialization. Most should use or actively discuss move semantics, lambdas, and other C++11 features. And it’s hard to write about existing features like virtual function overriding (as in GotW #5) without feeling something important is missing unless there’s also discussion of the way C++ has extended the existing feature, such as with override and final.

 

Second, I’ve decided not to target C++11 – rather, I’m going to write for C++14. Why would I do that, when C++ compilers [preemptive snarky remark: including my own team’s] are still catching up to C++11? For several good reasons:

• C++14 is going to be current C++ soon. As of April, it’s now feature-complete, and the detailed technical specification should be frozen this fall or winter (leaving time for ISO ballots and “’14” publication). Compilers and libraries are already aggressively implementing it. I wouldn’t be surprised if we had multiple fully-conforming C++14 implementations by the end of next year.
• C++14 is a small delta, a minor release aimed mainly at “completing C++11.” And it does complete C++11 well, to the point where as an author I really want to teach the complete story. I want to teach the complete “avoid writing new and delete” guidance that C++14 make_unique fully enables so that I can stop mumbling “except when you create a unique_ptr” as a special case. I want to write generic lambdas with C++14’s terse auto parameters that makes lambdas shorter to write and more flexible, and stop repeating parameter type names. I want to use C++14 move-capture in lambdas that makes them complete, and not feel obliged to talk about artificially putting objects on the heap and capturing shared_ptrs to them by value as a workaround for lack of move capture. And, in a few places where appropriate, I want to be free to use a few smaller C++14 tidbits like optional<T> that can affect interface design guidance now that they’re in the draft standard.

In addition, I’ve found that C++11/14 is changing my coding style, including my basic variable declaration style. I now think auto should be used consistently to declare local variables, even when you want to commit to a specific type(!) – this certainly surprised me, and likely will surprise you too, so I’ll cover that this year in a GotW and a recorded talk, no later than at C++ and Beyond later this year and possibly sooner.

 

I’ve converged on the above by updating the first dozen Exceptional C++ Items (in GotW order), trying out alternatives and seeing how well each one worked out. Those first dozen Items are now done and I’m pleased with the result, showing off auto and move and generic lambdas and mutexes/atomics and the new meanings of const and mutable and everything else, most of their code tested against various of the latest compilers, their advice updated to be current with current C++. And in every single GotW, no matter how short, it just felt right to:

• keep the topic, because each topic is still as relevant and useful as ever;
• revise the C++98 code and advice, because in every case both the code examples and the discussion was dated and/or incomplete, usually both; and
• skip C++11 to write directly for the complete story in C++14 without apology, because it let me avoid digressions for workarounds not needed in C++14, which made the text cleaner and simpler.

As I’ve revised Items, I’ve found that some updates are small but pervasive, such as using auto. Others are extensive, with entire subsections completely rewritten, thrown out as no longer relevant, or newly added to cover essential new sides of the story in modern C++. For example, GotW #6 about const-correctness is now a two-parter, covering the new meanings of const and mutable. Watch for it soon.

 

A word about numbering and sequence: My plan is to update and post most GotWs in numerical order starting with GotW #1, but every so often we’ll jump forward to new high numbers (starting with #89) as I create ones that weren’t originally a GotW – a Sutter’s Mill magazine article that wasn’t originally published as a GotW, or a brand-new C++14 topic. So for example you might see a sequence like “… 23, 24, 91, 25, 26, …”. All GotWs will have substantial new material, but the newly minted high numbers will be entirely on brand-new topics that didn’t arise in C++98 or just weren’t covered in GotW form before. (The handful of GotWs I wrote last year will be renumbered as they’re folded into the original series, either as updates or with new numbers in the original sequence if they’re on completely new topics. )

 

I’ll start posting fresh C++11/14 GotWs in the next few days. As usual, I’ll first post a problem by itself to invite discussion about possible solutions, then after there’s been time for comments I’ll post my own solution and the next problem.

It’s kind of exciting to write “GotW14” – today’s C++ really does feel like a fresh new language.

I hope you enjoy them as much as I enjoy writing them.

The Bristol meeting concluded a few hours ago, and I just posted my trip report on isocpp.org:

This afternoon in Bristol, UK, the ISO C++ standards committee adopted generic lambdas, dynamic arrays (an improved version of C99 VLAs), variable templates, reader/writer locks, make_unique, optional<T>, standard library user-defined literals, and a number of other language and library improvements – and approved the result as the feature-complete Committee Draft (CD) of Standard C++14 to be distributed for its primary international review ballot.

In addition to completing the C++14 CD document, the committee also made progress on three additional important parallel specifications that are on track to be published around the same time as C++14:

• File system library (draft), based on Boost.FileSystem version 3.
• Networking library, small at first and regularly extended.
• “Concepts Lite” language extensions (draft), to express template constraints and improve template usability and error messages.

Together these mark the C++ committee’s main planned deliverables for 2014. …

To provide just a sampling [of C++14], here are a few quick examples of some of the newly added features…

Continue reading…

On std-discussion, Shakti Misra asked:

I have seen in a lot of places code like
int i;
if(someConditionIstrue)
{
Do some operations and calculate the value of i;
i = some calculated value;
}
use i; //Note this value is only used not changed. It should not be changed.
But unfortunately in this case there is no way to guarantee it.
so now if some one comes and does

i = 10;// This is valid

What i was thinking: is there a way to tell that "i" can be set only once?
After that it will be a constant. Something like

const once int i;
if(someConditionIstrue)
{
Do some operations and calculate the value of i;
i = calculated value;
}
use i; //Note this value is only used not changed.
i = 10;// Compiler error

Olaf van der Spek replied:

A lambda?

I answered as follows:

Bingo. Olaf nailed it: The way to do it is with a lambda. This is one of the examples I give in my talk Lambdas, Lambdas Everywhere (here are the slides from C++ & Beyond 2010).

In your example, do this:

 

const int i = [&]{

    int i = some_default_value;

    if(someConditionIstrue)
    {
        Do some operations and calculate the value of i;
        i = some calculated value;
    }

    return i;

} (); // note: () invokes the lambda!

 

That’s the C++11 idiom for this. It’s still being absorbed though – not everyone knows about it yet as we’re still all learning C++11 styles together.

Bjarne Stroustrup wrote the following a few minutes ago on the concepts mailing list:

Let me take this opportunity to remind people that

• "being able to do something is not sufficient reason for doing it" and
• "being able to do every trick is not a feature but a bug"

For the latter, remember Dijkstra’s famous "Goto considered harmful" paper. The point was not that the "new features" (loop constructs) could do every goto trick better/simpler, but that some of those tricks should be avoided to simplify good programming.

Concepts and concepts lite are meant to make good generic programming simpler. They are not meant to be a drop-in substitute for every metaprogramming and macroprogramming trick. If you are an expert, and if in your expert opinion you and your users really need those tricks, you can still use them, but we need to make many (most) uses of templates easier to get right, so that they can become more mainstream. That where concepts and concept lite fits in.

Some of you may find this hard to believe, but "back then" there was quite serious opposition to function declarations because "they restricted the way functions could be used and the way separate compilation could be used" and also serious opposition to virtual functions "because pointers to functions are so much more flexible." I see concepts lite (and concepts) in the same light as goto/for, unchecked-function-arguments/function-declarations, pointers-to-functions/abstract-classes.

Reminds me of the related antipattern: “Something must be done. This is something. Therefore we must do it!”

I’m about two weeks late posting this, but two more C++ and Beyond 2012 videos are now available online.

The first is my concurrency talk:

C++ and Beyond 2012: C++ Concurrency (Herb Sutter)

I’ve spoken and written on these topics before. Here’s what’s different about this talk:

• Brand new: This material goes beyond what I’ve written and taught about before in my Effective Concurrency articles and courses.
• Cutting-edge current: It covers the best-practices state of the art techniques and shipping tools, and what parts of that are standardized in C++11 already (the answer to that one may surprise you!) and what’s en route to near-term standardization and why, with coverage of the latest discussions.
• Blocking vs. non-blocking: What’s the difference between blocking and non-blocking styles, why on earth would you care, which kinds does C++11 support, and how are we looking at rounding it out in C++1y?

The answers all matter to you – even the ones not yet in the C++ standard – because they are real, available in shipping products, and affect how you design your software today.

The second is one of the panels:

C++ and Beyond 2012: Panel – Convincing your Colleagues

From C++ and Beyond 2012, Andrei, Herb and Scott present Convincing Your Colleagues – an interactive panel.

Abstract:

You can’t do a better job if you don’t change what you’re doing, but change is hard.  It’s especially hard when what needs to change is your colleagues’ approach to software development. Moving your team forward often requires persuading your peers to change their behavior, sometimes to do something they’re not doing, other times to stop doing something they’ve become accustomed to.  Whether the issue is to embrace or avoid C++ language features, to adopt new development tools or abandon old ones, to increase use of or scale back on overuse of design patterns, to adhere to coding standards, or any of the plethora of other matters that affect software creation, moving things forward typically requires getting your colleagues to buy into the change you’re proposing.  But how can you do that?

In this panel session, Andrei, Herb, and Scott share how they go about convincing their colleagues to change and take questions from the audience.

Truth be told, the panel ranged widely and probably most of the time was on other topics!

I hope you find them useful.

With the help of friends Robert Seacord and David Svoboda of CERT in particular, I posted a note and link to their CERT post today because people have been misunderstanding the recent Java vulnerabilities, thinking they’re somehow really C or C++ vulnerabilities because Java is implemented in C and C++.

From the post:

Are the Java vulnerabilities actually C and C++ vulnerabilities?

by Herb Sutter

 

You’ve probably seen the headlines:

[US-CERT] Java in Web Browser: Disable Now!

We’ve been telling people to disable Java for years. … We have confirmed that VU#625617 can be used to reliably execute code on Windows, OS X, and Linux platforms. And the exploit code for the vulnerability is publicly available and already incorporated into exploit kits. This should be enough motivation for you to turn Java off.

Firefox and Apple have blocked Java while U.S. Homeland Security recommends everyone disable it, because of vulnerabilities

Homeland Security still advises disabling Java, even after update

Some people have asked whether last week’s and similar recent Java vulnerabilities are actually C or C++ vulnerabilities – because, like virtually all modern systems software, Java is implemented in C and C++.

The answer is no, these particular exploits are pure Java. Some other exploits have indeed used vulnerabilities in Java’s native C code implementation, but the major vulnerabilities in the news lately are in Java itself, and they enable portable exploits on any operating system with a single program. …

Some other C++ experts who have better sense than I do won’t add the following bit publicly, but I can’t help myself: Insert “write once, pwn everywhere” joke here…

At C++ and Beyond in August, I gave a 30 min talk on the changed meaning of const and mutable. The talk video is now online:

You Don’t Know [keyword] and [keyword]

const means const.

Bonus: mutable is useful and continues to mean ‘already as good as const.’

This is another way C++ has become simpler: const now means what people always thought it meant, and the four-line code example doesn’t need deep analysis at all – it just works.

But we analyze the four-line example anyway as a motivating case to see why and how it works, so we can fully appreciate this new simplification in C++11…