When we announced the CppCon conference program and I posted my final talk selection, the original plan for my Friday ‘endnote’ plenary was for it to focus on giving an update on future standardization plans. However, quite a few people immediately wrote me to express disappointment that I wouldn’t cover my Modern C++ Style material, which they felt was sorely needed as we build updated C++ usage guidance in the presence of everything that’s new in C++11 and C++14 which really do make C++ feel like a new and fresh language. At the same time, I noticed that the standardization material I had planned to cover will be covered very well in the Monday CppCon talk “What the Committee Did Next!” by Alisdair Meredith, chair of the Library Working Group of the C++ standards committee.
So I suggested that maybe we ought to repurpose my Friday plenary session with the other highly-requested topic instead, and the organizers agreed. Here’s the new description:
Back to the Basics! Elements of Modern C++ Style
by Herb Sutter
This talk revisits basic questions, such as how to declare and initialize a variable, how to pass a value to a function, how to write a simple loop, and how to use smart pointers, in the light of experience with C++11 and the latest C++14 refinements. This involves examining auto, rvalue references, range-for loops, uniform initialization, lambda expressions, unique_ptr and shared_ptr, and more.
Like all CppCon sessions, this talk will be recorded and is expected to be available online a month or two after the conference.
Note: If you’re in the Seattle area, note that Friday admission is free and open to all, as are evening and breakfast sessions, even if you don’t have a registration to see the other 100+ daytime technical sessions. (Though if you’re in the Seattle area and a C++ developer, why wouldn’t you register for the whole conference? Airfare and hotel are the majority of the total cost for most attendees, so if you’re local anyway this is some of the most inexpensive high-quality training there is. Just sayin’. Note that I am one of the CppCon organizers but I have no personal financial stake in CppCon – I’m not getting a penny from it – I’m just a delighted participant and attendee.)
I’m looking forward to seeing many of you at CppCon!
Sutter’s Mill 
Herb, I’m not sure I agree with set_name(const string&). I think const string& is almost never right, it should be string_view (or something like it).
Even without string_view:
With string& you’re forcing the caller to have the data in a string, which might require a copy (and allocation). Worst-case this means two copies and allocations per employee.
I’m also wondering whether the benchmark is representative. Employees don’t change names often and personally I don’t re-use employee structs, so there’s never existing capacity to re-use.
Is there a recording of the talk?
I saw your presentation and wanted to ask a question about it but didn’t get a chance to. If I missed something and you addressed this already I appologize.
Sometimes you want to use auto because you’re duck typing but you really can’t, or at least I have trouble coming up with a resonable way to. The issue I’m thinking of was not in your list of cases. An example would be something like so:
template
void foo(Cont & c)
{
auto x = c[0]; // 0 could be whatever.
// … do something here that could cause c to reallocate and move, invalidating all references and pointers.
fun(x);
}
The issue here is obviously that `operator []` might return a `reference_wrapper`. In this case your intention was to get your own copy of an element in that container and everything would be fine. You’re duck typing…you don’t care what that type actually is, only that you can fun it, but you really do need your own copy or you’re going to have a bad time.
I’ve read about a proposal for an operator that library implementors could override so that if auto is used to deduce the type it will give them the right thing. I don’t know the status of that proposal though and also wonder what your advice would be in the meantime. Do you have an ellegant solution for this that fits into the, “default to auto,” framework you advocate…or is it just a problem that needs a solution?