Tag Archives: Herb Sutter

C++17 News

Herb Sutter blogged about the Oulo ISO C++ meeting. There’s a link to an interview he did for the excellent CppCast podcast and also to a reddit post on features approved at the meeting.
CppCast

As Herb called out in the interview, I think the following two features will be widely used:
Structured Bindings
This is interesting because I’ve been using the std::tie syntax for a while, despite the clumsiness when you need to introduce new variables to take the return types (leaving them uninitialised until assignment). The proposal above avoids that problem.

tuple<T1,T2,T3> f(/*...*/) { /*...*/ return {a,b,c}; }

// BEFORE
T1 x;
T2 y;
T3 z;
std::tie( x, y, z ) = f();

// AFTER
auto [x,y,z] = f(); // x has type T1, y has type T2, z has type T3

Initialisation clause for if and switch
This proposal makes if/switch more consistent with for loops that allow separate initialisation/increment clauses as well as a condition. So now you can initialise a variable separately from the if condition, which also allows you to limit the scope of that variable.

// BEFORE
status_code c = bar();     
if (c != SUCCESS) 
{       
    return c;     
}

// AFTER
if (status_code c = bar(); c != SUCCESS) 
{     
  return c;   
}

Leave a comment

Filed under C++, Programming

Video: Herb Sutter Back to the Basics at Cpp Con 2014

Herb Sutter’s Back to the Basics video is hardly an introduction to C++ as the name suggests. Rather, it clarifies his default choices when faced with some basic tasks like parameter passing, in the light of modern C++ techniques.

Don’t pass owning choices down the call stack – use non-owning raw pointers and references when you don’t need ownership transfer down the call stack, e.g. when callee parameter’s lifetime entirely nested within the called method. If the called method doesn’t participate in ownership, it should be agnostic to the lifetime of the object, whether on the stack, the heap, global, shared_ptr or unique_ptr.
image

Another reason to use auto is performance – it guarantees no implicit conversion because there’s no explicit declared type.
20150326-120815.jpg

Reviewing parameter passing choices, established rules of thumb still apply, they just got better.
20150326-121118.jpg
This is especially true for pass-by-value, which experts considered to be the new default choice for a while for moveable types, but is now only recommended for constructors that wish to retain a copy.

There was a bonus slide on returning multiple values using std::tie, which I’ve been doing for a while.
image

Finally, it seems that there’s a new term for Universal References – “Forwarding References”. I agree that this states the intention of T&& parameters better that Scott Meyer’s original name, although my eBook of Effective Modern C++ still uses the old name.

Leave a comment

Filed under C++, Programming, Video

Video: Herb Sutter on Visual Studio cross platform development

Exciting times for C++, you can now target multiple compilers and platforms from a single IDE, Visual Studio.

IMG_3544.PNG

IMG_3545.PNG

Leave a comment

Filed under C++, Programming, Video

Herb Sutter GotW94: AAA Style (Almost Always Auto)

Herb Sutter’s Guru of the Week article on Almost Always Auto is a tour de force covering everything you always wanted to know about auto.

Leave a comment

Filed under C++, Programming

Herb Sutter GotW91: Smart Pointer parameters

Herb Sutter’s guidelines on passing smart pointers as parameters include the following:

  • Copying smart pointers incurs two performance hits:
    • Cost of increment and decrement on the internally synchronised reference count
    • Scalability woes due to cache contention on the shared reference count
  • Passing a shared_ptr by value implies taking shared ownership. A copy is needed anyway, so incurring copying cost is fine.
  • Don’t use a const smart_ptr& parameter because it exposes the function to the caller’s lifetime management policy. Use a Widget* instead.

Guideline: Don’t pass a smart pointer as a function parameter unless you want to use or manipulate the smart pointer itself, such as to share or transfer ownership.

Guideline: Prefer passing objects by value, *, or &, not by smart pointer.

Leave a comment

Filed under C++, Programming

Herb Sutter GotW89: Smart Pointers

Herb Sutter’s GotW89 Smart Pointers post includes good reasons to use make_shared/make_unique instead of naked new. Avoiding memory fragmentation is one of those:

Separate allocation

auto sp1 = shared_ptr<Widget>{ new widget{} };
auto sp2 = sp1;

Separate allocation

Single allocation
If you use make_shared to allocate the object and the shared_ptr all in one go, then the implementation can fold them together in a single allocation.

auto sp1 = make_shared<Widget>();
auto sp2 = sp1;

Single allocation

Leave a comment

Filed under C++, Programming

Herb Sutter GotW6: Const and Mutable

This item covers ground Herb already presented in this video. He recommends that const member functions must be one of:

  • truly physically/bitwise const with respect to this object
  • internally synchronized so that if it does perform any actual writes to the object’s data, that data is correctly protected with a mutex or equivalent (or if appropriate are atomic) so that any possible concurrent non-const accesses by multiple callers can’t tell the difference.

Similarly, he asserts that the guidelines taught for C++98, that const means logically const but you had a free rein with internal data, is no longer true for C++11 with its memory model and thread safety specification.

This implies stricter best practice on use of mutable member variables. Any time you need to mutate data in a const member function, you should protect it with a synchronisation object to ensure thread safety.

Leave a comment

Filed under C++, Programming