CppCon 2018: Titus Winters “Modern C++ Design (part 1 of 2)”
Vložit
- čas přidán 21. 10. 2018
- CppCon.org
-
Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/CppCon/CppCon2018
-
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.
-
Videos Filmed & Edited by Bash Films: www.BashFilms.com
*-----*
Register Now For CppCon 2022: cppcon.org/registration/
*-----*
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 ;)
This talk should've included more examples. It's very hard to follow.
What happened to part 2? I started listening to it a few hours ago and now it's gone?
The title of this video shoul have its own namespace in order to disambiguate its ambiguity in the mindset of audiences;
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.
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.
Yes, 'modern' design across most languages has been naming over comments. "comments considered harmful" if you will.
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 :)
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.
If the char* version of the c'tor copies the data, there's no bug---the string that was passed to Foo(string&) is guaranteed to survive the statement (including nested calls).
@@JasonRennie I mean that there MIGHT be a logical bug: if an author wanted to forward object creation to another ctor then there is a bug. If he relied on side effects of Foo creation and destroying then there isn't.
There is absolutely no bug. The main implementation is in foo(const char*). The string one passes the const c str pointer to that function. No object is also created . Just either a 64bit stack push or register load.
The talk itself is not that interesting. Didn't really learned anything .
Video title is wrong. This is specifically about APIs.
Yeah, three very important letters were dropped! :)
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
He should read less from his notes and use a better phrasing. Really hard to follow
The presentation was less than exciting.
1st
Awesome!