CppCon 2018: Titus Winters “Modern C++ Design (part 1 of 2)”

—
—
The old rules for C++API design are due for an update - we have made ad hoc changes to design principles in the standard library, but haven’t really written down the new ideas. Parameter passing and API design for free functions/member functions is due for a general update, particularly as a result of rvalue-references and reference qualification. How do we pass non-owning references? How do we sink a T? How do we express “maybe move” APIs? When do we want reference-qualified overload sets? What does an rvalue-reference qualified non-overloaded method mean? How do we express call once semantics?

For types, our consistency in producing Regular types has weakened in recent C++ releases with types like unique_ptr (move-only) and string_view (reference semantics). These classes of design that have shown themselves to be valuable, but certainly surprising at first. As we should not continue to extend the set of type designs arbitrarily, this is a good time to look at type design in the modern C++ era and narrow down the set of designs that are generally favored. This talk will focus on modern C++ design from small (choice of passing by value or reference) to large (Regular types, reference types, move-only types, etc). We will also introduce a taxonomy of type properties as a means to discuss known-good type design families.

We will also dive into the discussion of whether Regular design covers all good design, or whether there is more to the story.
—
Titus Winters, Google
C++ Codebase Cultivator

Titus Winters has spent the past 6 years working on Google's core C++ libraries. He's particularly interested in issues of large scale software engineer and codebase maintenance: how do we keep a codebase of over 100M lines of code consistent and flexible for the next decade? Along the way he has helped Google teams pioneer techniques to perform automated code transformations on a massive scale, and helps maintain the Google C++ Style Guide.
—

*-----*
*-----*

[ukaszdrozdz]

The youtube title is misleading. The word "API" is important here, as most peaople when reading “Modern C++ Design" think of Andrei Alexandrescu's book ;)

[PixelPulse]

This talk should've included more examples. It's very hard to follow.

[PeterSommerlad]

I would have loved if Titus would have emphasized that the functions in an overload set should clearly be spelled what they are doing instead of relying ad saying a single comment saying what they do.

[voltairespuppet]

Parse a unique ptr by ref can make sense if considering it as a maybe-parse ownership. If it is null after then ownership is taken. Otherwise temporary read access was used.

[shahmiBro]

The title of this video shoul have its own namespace in order to disambiguate its ambiguity in the mindset of audiences;

[Saethlin]

What happened to part 2? I started listening to it a few hours ago and now it's gone?

[MeerMusik]

Hello "Video People": 1st: Thanks for your work. 2nd: Some Videos exist 3x times right after each other, some with multiple Parts are spread far out in the Playlist (Part 2 for this Video is now Number 93 after you uploaded more Videos). I guess your scripts could use a slight overhaul.

No offense. Just meant as a hint :)

[jhbonarius]

Video title is wrong. This is specifically about APIs.

[SuperMopga]

There is a bug at 9:11 in Foo(const std::string& s ). That will create temporary Foo in ctor and drop it off right there.

[WiktorWandachowicz]

I don't like too much API like presented at 41:35. This is supposed to be a helpful set of overloaded methods, yet it adds extra effort to check if the code uses correct variant of method. I think this is something that could/should be rather optimized by compiler. There is tendency to write "new" code using more abstractions, duck typing, concepts, and higher-level constructs. But at the same time serious programmers need to be constantly aware of memory allocation, ownership of pointers to chunks of memory, when temporaries are created and destroyed, difference between copy and move semantics, and so on. Otherwise sharp edges will hurt you.
For me C++ was once a beautiful language. For the sake of memory access optimizations it gains more advanced features. Sometimes it seems like most of these features are designed for std::string, which now it even has std::string_view as its counterpart. However std::string, char and char* are not even Unicode-aware! Couldn't C++ incorporate "byte" type instead of "char" and fully support Unicode? But then the compatbility with heaps of *old* code would be lost... And it makes teaching C++, not to mention learning, harder and harder.
I await when from C++ emerges the "simpler language" as Bjarne Stroustrup once mentioned. But I slowly loose hope for this. /s

[sergiip]

He should read less from his notes and use a better phrasing. Really hard to follow