Last night's talk video is online: Quantifying C++'s accidental complexity, and what we really can do about it

The ISO C++ committee is here in Prague this week to finish C++20, and the meeting hosts Avast Software also arranged a great C++ meetup last night where over 300 people came out to see Bjarne Stroustrup, Tony Van Eerd, and me give talks. The videos are already online, see below — they’re really high quality, and it was a great event. Thank you again to everyone who came out to see us! You made us feel very welcome in your beautiful city and your enthusiasm for C++ is contagious (in a good way!).

Mine was a brand-new talk with material I’ve never presented on-camera before. (I gave a beta version at ACCU Autumn last November in Belfast.) I’m really excited about this upcoming work that I’m planning to bring to the committee in the near future, and I hope you enjoy it.

Thanks again to Hana Dusíková for her hard work organizing this meetup and this entire week-long record-shattering C++ standards meeting, by far the largest in history with 250 attendees. But there’s no rest for the competent — she still has to chair SG7 (reflection and compile-time programming) all day tomorrow. :) I’ll be there!

8 thoughts on “Last night's talk video is online: Quantifying C++'s accidental complexity, and what we really can do about it

  1. @Nicolas: Thanks!

    @Petke: I hear you. :)

    @bcs9: Yes, it’s fully compatible with calling existing functions. For example, an “in” parameter is simply treated as a const lvalue inside the function body for all purposes including for passing it onward to an existing overload set, except that the definite last use treats it as an rvalue (only if the actual argument is an rvalue) which naturally selects any rvalue overloads for the function it’s being passed to.

    @RJ: Thanks, I think this has been fixed now.

    @Matt: Right, so if you want to reuse the variable just make a local copy. (This is arguably already a good practice anyway for code clarity rather than reusing the by-value parameter directly.)

    @Dan: Yes, the paper also mentions two kinds of return, which I didn’t have time to cover as this talk only had about an hour. I plan to cover return values and also the “this” parameter in the future when I have a 90-minute slot, likely at CppCon this autumn.

    @Jiří: The nice thing is that if you want to declare a function that can take any kind of cv-qualified or l/r-value argument (which means it wants to read from it and possibly copy it), just declare “in” and write a single function. But yes you can additionally overload on these, and the compiler will select the best match based on the restrictions on the argument.

  2. Your talk is a very interresting proposal. That would certainly simplify things.

    However I am wondering about certain details of the “in” and “out” semantics with respect to library functions. If I understand it correctly, in can take const lvalue or rvalue reference. And out can take reference to either old constructed object or uninitialized memory. With multiple such parameters, the number of possible combinations grows. If the compiler sees the function definition, then it can generate variants on demand as it does with forwarding references. But what if the function is part of some library interface?

    Does the library need to contain functions for all possible combinations of l/rvalue in and (un)initialized out parameters? Or is there some way to opt out from allowing rvalue references for some in parameters? Or am I completely wrong?

  3. I really enjoyed your talk and I especially like the idea of specifying “what” in parameter passing instead of “how”.

    I’m wondering if you’ve given any thought to returning values from functions/methods? For example, between moving the result vs “lending” a member via a reference.

  4. Thank you. I enjoyed the talk and hope something like that comes to pass for passing. One quick issue with [in] parameters is often “by value” parameters that are modified, especially in math routines, as they not only act as parameters but also working storage/scratchpads. Using locals and lifetimes analysis could supplant that so it is just an optimisation issue I’d think, but it is something that is different to now and may trip up simplistic automated conversions.

  5. The videos are marked as content made for kids. So it is not possible to save them to playlist and save to watch later.

  6. I suspect that in a stable pure c++ context that would work rather well. But what about things like C APIs? Is there a viable incremental migration path? (What does Titus Winters have to say?) I’m also a bit concerned that there will be no indication at the call site which mode is being used. What pathologies will spring up from the callers assumptions and the function’s intentions not matching?

  7. Great proposal. Hope it makes it into the standard some day. I think C++ might be a hoarder. Maybe it’s time for a spring cleaning, so that when the neighbours come and visit one won’t have to apologise for the mess.

In comments, use [code] [/code] for code blocks, and the same with angle brackets for code inside text paragraphs. I appreciate and try to acknowledge feedback on GotW articles; if you're suggesting an improvement for a GotW Solution post, please post under your real name (or include it in the comment text) if you would like to be acknowledged here and when the material is updated and expanded in future Exceptional C++ books.

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s