Session Topic: You Don’t Know [keyword] and [keyword]

I plan to give a brand-new talk for the first time at C&B, but I’m conflicted regarding what to say about it here because it’s recently been a bit of a startling realization to me about C++11, and I think it may be a bit startling for others too. I don’t want to be a tease, but I also want to save it as a surprise for C&B itself.

In the meantime, here’s a teaser…

In addition to the many new C++11 features that everyone’s listing, it has dawned on me over the winter that there’s actually another major change that isn’t being talked about anywhere, or even being listed as a change in C++11 at all as far as I know, because I and other key experts and committee members I’ve asked didn’t fully realize that we altered the basic meaning of not one but two fundamental keywords in C++. It’s a change that has profound consequences, that rewrites and/or invalidates several pieces of pre-C++11 design guidance, and that’s directly related to writing solid code in a concurrent and parallel world. This isn’t just an academic change, either — everyone is going to have to learn and apply the new C++11 guidance that we’ll cover in this session.

I plan to talk about it first at C&B, in a session tentatively titled as above — I’ll fill in the keywords later. You may already guess a few keyword candidates based on the description above, and here’s a final hint: You’ll hardly find two C++ keywords that are older, or whose meanings are more changed from C++98 to C++11. (No, they aren’t auto and register.)

Herb

C++ and Beyond 2012: Aug 5-8, Asheville, NC, USA « Sutter’s Mill Says:

March 26, 2012 at 4:37 am

[…] the title really is “You Don’t Know [keyword] and [keyword],” at least for now. Here’s the description I just posted: I plan to give a brand-new talk for the […]

Dan Says:

March 26, 2012 at 7:04 am

If I had to guess, I’d say “volatile” and “const”?

I’m not very familiar with the new standard, but I understand there is a new memory model, and I know from all my work in the embedded world that understanding the underlying architecture & memory model is incredibly important.

Herb, I don’t expect you to confirm or deny anything, just throwing my (uneducated) guesses out there!

Mike Says:

March 26, 2012 at 7:27 am

‘static’ and ‘const’ are my best guess. ‘volatile’ takes the bronze.

Scott Meyers Says:

March 26, 2012 at 11:17 am

Herb, please tell us you and your colleagues didn’t change the meaning of “int” or “return”…

But I can think of lots of interesting possibilities for new semantics for “break” :-)

Scott

Michel Lemay Says:

March 26, 2012 at 1:40 pm

Probably ‘static’ and ‘volatile’.. If I’m not mistaken, static has some guarantee of thread safety initialization.. And volatile should now have a valid memory semantic contrary to the old C.

Herb Sutter Says:

March 27, 2012 at 1:15 pm

@Scott: Since you mention return, that reminds me that (as you know) we did in fact extend the meaning of return in at least two ways: In C++11, “return expr;” now automatically moves from the object created by the return-expression (this mostly falls out of its being an rvalue, but still), and you can “return { some, initializers };” too. So there. :) Still, those are relatively small changes that extend, but don’t really invalidate or change, the meaning/guidance around return statements… return is not what I have in mind.

Scott Meyers Says:

March 29, 2012 at 10:15 am
@Herb: Well, to be quite technical about it, return expr doesn’t automatically move, because it’s possible that the type in question doesn’t support move. In that case, the expression gets copied. This is part of a topic I plan to address in a different talk I’ll be giving at C&B, but the gist of the argument is that it’s a mistake to assume that moving is cheaper than copying, because that’s not true for all types. Unless you know the types involved, the best you can do is request or enable a move, because if the type in question supports only copying, your request or move-enablement (move-enablement?) will be in vain. This has implications for template authors, because they rarely can assume that the types they are dealing with are move-enabled.

Scott