The C++ rvalue Lifetime Disaster - Arno Schoedl - C++ on Sea 2023

cpponsea.uk/
---
The C++ rvalue Lifetime Disaster - Arno Schoedl - C++ on Sea 2023
Rvalue references have been with us since C++11. They have originally been introduced to make moving objects more efficient: the object an rvalue reference references is assumed to go out of scope soon and thus may have its resources scavenged without harm. The C++ standard library, for example std::cref or std::ranges, makes use of yet another aspect of rvalue references: since they go out of scope soon, it is assumed unsafe to hold on to them beyond the scope of the current function, while lvalue references are considered safe. We, too, found this assumption to be very useful for smart memory management, in particular in generic code.
Unfortunately, the C++ language itself violates this assumption. Rvalues bind to const&. This means that innocent-looking functions silently convert rvalues to lvalue references, hiding any lifetime limitation of the rvalues. Temporary lifetime extension is meant to make binding a temporary to a reference safe by extending the lifetime of the temporary. But this only works as long as the temporary is a prvalue, and already breaks with rvalue references, let alone spuriously generated lvalue ones. These problems are not merely theoretical. We have had hard-to-find memory corruption in our code because of these problems. In this talk, I will describe the problems in detail, present our library-only approach to mitigate the problems, and finally, make an impossible-to-ever-get-into-the-standard proposal of how to put things right.
---
Slides: github.com/philsquared/cppons...
Sponsored by think-cell: www.think-cell.com/en/
---
Arno Schoedl
think-cell founder & CTO.
Arno is responsible for the development of all think-cell software products. He oversees our R&D team, quality assurance and customer care. Before founding think-cell, Arno worked at Microsoft Research and McKinsey. Arno studied computer science and management and holds a Ph.D. from Georgia Tech with a specialization in computer graphics.
---
C++ on Sea is an annual C++ and coding conference, in Folkestone, in the UK.
- Annual C++ on Sea, C++ conference: cpponsea.uk/
- 2023 Program: cpponsea.uk/2023/schedule/
- Twitter: / cpponsea
---
KZbin Videos Filmed, Edited & Optimised by Digital Medium: events.digital-medium.co.uk
#cpp​ #cpponsea​ #cppprogramming​

[@richtourist]

If you really want to understand C++ ask an anthropologist.

[@ErnestHecken]

Agner Fog reference?

[@richtourist]

I was trying to imply that C++ is not an intentional design by human logic, but a haphazard evolution by human nature. I had never heard of Agner Fog, but I have now, thanks! What an interesting guy. I have often thought that the complexity and obscurity of C++ gives rise to superstitious practices; I wonder if Agner Fog has any views on that. @@ErnestHecken

[@samanthaqiu3416]

this presentation is brilliant, and the idea of switching the binding rules between long and short lifetimes makes soooo much sense

[@yooyo3d]

You made C++ funnier than JavaScript. The whole point is: when you find yourself in such situations you just made the wrong decisions way before. Just stop, go back, fix it, learn, and try to not repeat again.

[@wizardy6267]

Is that the reason ppl stop using JS and go typescript?

[@CraftMine1000]

I'm seriously starting to believe that the numbers they put at the end of C++ is for how much jank and boilerplate was added in that version

[@richtourist]

Someone once paraphrased Steve Taylor's statement into: The 11 in C++11 is the number of legs they nailed onto std::dog to make std::octopus

[@foo0815]

It's just a mess beyond any repair...

[@olafschluter706]

Don't get it how someone will find this whole stuff easier to comprehend than the borrow checker of Rust.

[@Stasenko58]

With all due respect using pragmas to controll binding rules is an absolute no go. Firstly it makes reasoning about the code and reading it much harder, since now there are 2 conflicting gramatic rules in play you have to know which one is in use at this point in time, and this will require at minimum scanning entire file to the nearest pragma declaration (or even having to look into includes). Secondly it may result in ODR violations and other problems. Depending on what are the rules with including, something will break. Be it just functions, templates (especially msvc token streams) or macros. C++ has a lot of unfixable issues and this is just one of them. And quite frankly there is no way to fix it... Well at least not in scope of c++ standard, but perhaps cppfront is an answer to resolve c++ problems

[@muhdiversity7409]

Sigh. I've been catching up with things and all I can say is the language just gets worse and worse with more and more pitfalls.

[@robmorgan1214]

Copy is better when it allows for contiguous memory on the stack. Out of order access usually hurts more than copy to local stack housed in registers in cache... when writing this kind of code the abstraction HURTS. Best rule of thumb arrays always faster than fancy big o structures, copy always faster when it prevents load or store from main memory. Move only faster when everything is already in cache. Too much interference from the language leads to bad code generation. Write your code to use your hardware if the compiler and language help... great. But this kind of nonsense is not helpful to express the business logic, guarantee its correctness, or maximize its performance. Why...cpp standards committee... why... it's rust envy isn't it?

[@cristian-si1gb]

How old is this presentation? The code at 3:12 does compile now, the view will now own the vector inside of it

[@Roibarkan]

33:56 I wonder if c++23 “deducing this” can be used to create a new idiom for accessor member-functions, which deals with that specific amnesia. Great talk

[@raymundhofmann7661]

What about simply avoiding life time troublesome reference constructs and compiler static checks to help?

[@kayakMike1000]

If you're trying to create new idioms for C++ l, you're already circling the drain. You're drying your towels in the rain. You're putting lipstick on a pig. The only idiom for C++ I hope for is C++ pushing up daisies!

[@muhdiversity7409]

@@kayakMike1000 I swear the "standards" committee either hates the base language and are making it worse for laughs or a cynical attempt to sell more of their books on how to navigate the unholy mess.

[@Spartan322]

@@kayakMike1000 C++ is too developed and standard as it is, and has too many necessary features that can't be replaced and for which no one else implements, and C++ itself is already a complex beast of a language built on all these individual features, Rust and Zig are not C++, they might be able to overtake C, but until they support the metaprogramming feature set of C++ performantly without wasting compile time unnecessarily, and especially without the "you don't pay for what you don't use" principal, no language will overtake C++.

[@Lalasoth]

​@kayakMike1000 I'm curious if you despise c++ so much then Why are you watching this?

[@tal500]

Another possibility that came to my mind - define a template class "long_const" that acts like the correct behaviour of a (long) const reference. This way, old code could still treat "const&" efficiently the same as "count&&" (you'd still need to enforce it or to be careful)

[@szaszm_]

Would any reasonable code break by disallowing binding xvalues to `const &`? If the breakage is limited, maybe we could change the rules to only allow prvalues to bind to `const &`.

[@ZeroPlayerGame]

Well, TLE needs to bind to xvalues

[@N....]

15:58 wait, why can't you just declare the variable as decltype(auto)? It should exactly match the return type of the function in that case, right? So if the function returns by value, the variable will also be a value, right? If it's an rvalue reference instead that is news to me!

[@OMGclueless]

This mishandles rvalue references. If someA returns an rvalue reference then no lifetime extension will occur (because it's a reference and there's nothing to extend). Then when you go to return a, the reference is dangling.

[@SvetlinTotev]

This language is unsalvageable. The problem is the replacements aren't good enough either.

[@aniketbisht2823]

15:25 you should be using decltype(auto) instead of auto const& and it would have just worked (in C++23).

[@Adityarm.08]

The more I try to learn c++, the more it makes me appreciate rust.

[@The_Gray_Zone_Man]

Actually I don't know if it's about the difficulty of this presentation or just is my adult ADHD that is to blame for the distortion in my mind, Thanx for the effort anyways

[@xavierdupont5772]

That's a very well done présentation, but it seems to me that the language is trying to get to smart znd fails. It should be immediately obvious whether a function returns a reference or a copy, and it seems to be that the language made the mistake to use copy everywhere then now tried to remove that automagically with move semantics, and fails. when it should have just been using vectors of pointers and not try to make the language more "sexy". Programmers in C/C++ are supposed to know what pointers are, love them. think about whether the objects they point to are living on the heap or on the stack, and not return reference to temporary variables unless they know what they are doing. Which kind of Pandora box did lead to this mess ?

[@kayakMike1000]

Seriously. Why do people bother with C++ when its so remarkably BAAAD.

[@Spartan322]

Zig and Rust still can't compare to C++, they're designed to overtake C, C++ still beats them on functionality and metaprogramming. Rust is not really even designed to be a C++ replacement, least not as its currently developed, anyone who thinks otherwise doesn't understand C++ nor Rust.

[@Baptistetriple0]

This presentation was more "how to get dangling references in 30 simple exemples", the fact you can have UB so easily is a nightmare. I know Cpp is not going anywhere soon, but there are languages nowadays that are on par performance wise and don't feel like walking in a landmine. Zig and Rust don't have the same maturity than Cpp, but are very promising languages that with some time could really make Cpp the last choice.