Tag Archives: Herb Sutter

Video: Meta – Toward Generative C++, Herb Sutter

Herb Sutter shared this video of his Qt 2017 talk on his personal metaclasses project.  

 

I first heard about this development at ACCU 2017. The benefits of standardising best practices for definitions of interfaces/value types etc are huge and would let the developer concentrate more on the business problem they are solving, rather than the technicalities of the language. 

  

Leave a comment

Filed under C++, Programming, Uncategorized, Video

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