emailaddress:titus@google.com

Tip of the Week #148: Overload Sets
▻https://abseil.io/tips/148

Originally posted as TotW #148 on May 3, 2018

by Titus Winters, (titus@google.com)

One of the effects of living with electric information is that we live habitually in a state of information overload. There’s always more than you can cope with. –Marshall McLuhan

In my opinion, one of the most powerful and insightful sentences in the C++ style guide is this: “Use overloaded functions (including constructors) only if a reader looking at a call site can get a good idea of what is happening without having to first figure out exactly which overload is being called.”

On the surface, this is a pretty straightforward rule: overload only when it won’t cause confusion to a reader. However, the ramifications of this are actually fairly significant and touch on some interesting issues in modern API (...)

Tip of the Week #149: Object Lifetimes vs. =delete
▻https://abseil.io/tips/149

Originally posted as TotW #148 on May 3, 2018

by Titus Winters, (titus@google.com)

Into the blue again after the money’s gone Once in a lifetime, water flowing underground –David Byrne

=delete for Lifetimes

Imagine you have an API that requires a reference to some long-lived object, but doesn’t take ownership of it.

class Request ...

// The provided Context must live as long as the current Request. void SetContext(const Context& context);

You think to yourself, “Hey, what happens if someone passes a temporary? That’s going to be a bug. But this is modern C++, I can prevent that!” So you rig together a change in the API, adding a deleted overload.

class Request ...

// The provided Context must live as long as the current Request. void SetContext(const Context& context); (...)

Tip of the Week #24: Copies, Abbrv.
▻https://abseil.io/tips/24

Originally posted as TotW #24 on Nov 26, 2012

by Titus Winters, (titus@google.com) and Chandler Carruth (chandlerc@google.com)

“To copy others is necessary, but to copy oneself is pathetic.” - Pablo Picasso

Note: see also TotW #55 and TotW #77 for guidance on name counting and copies vs. moves.

One Name, No Copy; Two Names, Two Copies

When evaluating whether copies get made within any given scope (including cases triggering RVO), check how many names your data refers to.

You will have two copies of the data at any point where you have two live names for those copies. To a good first approximation, the compiler will (and often must) elide copies in all other cases.

Between the move semantics of STL containers (introduced automatically with the switch to C++11) and copy constructor (...)

Tip of the Week #88: Initialization: =, (), and {}
▻https://abseil.io/tips/88

Originally posted as TotW #88 on Jan 27, 2015

by Titus Winters (titus@google.com), on behalf of the Google C++ Style Arbiters

C++11 provided a new syntax referred to as “uniform initialization syntax” that was supposed to unify all of the various styles of initialization, avoid the Most Vexing Parse, and avoid narrowing conversions. This new mechanism means we now have yet another syntax for initialization, with its own tradeoffs.

C++11 Brace Initialization

Some uniform initialization syntax proponents would suggest that we use s and direct initialization (no use of the ‘=’, although in most cases both forms call the same constructor) for initialization of all types:

int x2; std::string foo"Hello World"; std::vectorint> v1, 2, 3;

vs. (for instance):

int x = 2; std::string foo = "Hello (...)

What Should Go Into the C++ Standard Library
▻https://abseil.io/blog/20180227-what-should-go-stdlib

By Titus Winters (titus@google.com), @TitusWinters

About the Author - Titus holds a PhD in Computer Science Education from UC Riverside. He created most of Google’s internal C++ coursework, and plays an active role in the C++ mentoring program that serves several thousand Google C++ engineers. He has been deeply involved in C++ library infrastructure since 2011, through the Google C++ Library Team and now Abseil. He chairs the Library Evolution Working Group (LEWG) - the sub-committee of the C++ Standard that focuses on the design of the C++ standard library.

A few interesting pieces on the direction and design for C++ have circulated recently. First off, I strongly recommend everyone read through Direction for ISO C++ ; it provides a lot of excellent detail and suggestions, as (...)