Taking a Byte Out of C++ - Avoiding Punning by Starting Lifetimes - Robert Leahy - CppCon 2022

[@MrGooglevideoviewer]

Wow... Robert is a Fantastic presenter!!

[@Adowrath]

A talk by Robert Leahy is always a delight to watch.

[@TonyPianoSheets]

I just discovered this talker and he’s amazingly good at explaining things with such simplicity! Absolutely suggested talk!

[@MattGodbolt]

What a great talk - thanks so much for sharing all this. Time to update a ton of code that's relying on "hopefully the compiler never spots this is UB" tricks!

[@superscatboy]

I totally get why you're drip feeding these videos one every day, and I'm absolutely not complaining... But good lord the suspense is killing me lol

[@Ariccio123]

I'm really glad to see that c++ is finally developing the tools to do true zero cost abstractions, SAFELY

[@KobiCohenArazi]

This is by far, one of the best talk _ever_ !

[@bluespeck]

The bit about returning a pointer to a T and not the pointer to an uncollapsed wave function was soo good! :))

[@Horizon-jq6bf]

this guy is an amazing public speaker, great talk

A great and well presented talk!

[@JohnDlugosz]

"It's difficult to imagine writing programs without memory" ATARI ! For those who don't know, the original ATARI VCS, later called the 2600, only had 128 bytes of RAM. It did not have a pixel map display buffer, either, which is unthinkable. Generating the image was done by "racing the beam".

[@puppergump4117]

Tech was certainly more interesting back then

[@meneldal]

Aliasing rules is probably what creates most of the UB when reading C programs as C++. I do agree that aliasing rules in C++ are good in most cases, but if you could go back and redo the language. I'd made everything restrict by default (no matter the type), and you'd have to annotate when things can actually alias and just let people do type punning between various sizes with implementation specified behaviour.

[@kronek9371]

Couple questions on 23:03. I know it's not supposed to be a real example, but just in case I am missing something, 1. For this to be defined, does the ptr need to be alignas(int)? What if the passed in ptr have the wrong alignment (or wasn't even a const int* originally anyway) 2. Why reinterpret_cast(byte_ptr) rather than static_cast(byte_ptr)

[@ciCCapROSTi]

Gonna be honest, this way way over my head. I need to catch up on the modern (past 11) memory model and whatnot. But as far as I could follow, great talk.

[@xequals-pc1wl]

C++ - overcomplicating things every day.

[@kodirovsshik]

First time?

[@ABaumstumpf]

There are people that claim C++ is not getting more and more abstract and detached from the needs of developers. Having to think about some arbitrary rules about type-lifetime collapse for automatic-lifetime-types when using malloc is anything but simple, intuitive or useful. The idea of lifetime seems simple but C++ has made dealing with that way more complicated than needs to be.

[@drj9403]

this guy is so coool

[@codingfinance6080]

Whoa! 😮 This talk was crazy impressive

[@dexterman6361]

Amazing talk! If I am allowed to be jovial, this guy could make me cry just by saying "and in the destructor, we DESTROY those bytes". He has so much ... feels, to what he's saying :P Edit: Also, how does one get this good? How can I understand better by just reading the spec? How can I better reason about things?

[@rationalcoder]

You get good by not worrying about getting good at C++. Think about it as getting good at native programming. Implement real applications, and struggle through what's available in your language to generate the code you would want to generate if you were writing the assembly yourself.

[@jaybee9054]

..like he's narrating an audio book 😆 Interesting style!

[@waldolemmer]

I love this guy

[@SardarNL]

Brilliant talk. We may see a readable vector implementation after all.

[@kodref]

This is a great and to the point talk!

[@Swedishnbkongu]

If update derives from erased_update, why wouldn't you just call timestamp() on the derived (update) object, the member function should still be available. Why need std::launder and use the old pointer to the parent type?

[@kodirovsshik]

Thank you for the awesome talk sir

[@tobiaslangner267]

great talk, thank you.

[@neilholmes1016]

in your start_lifetime_as function you missed std::launder, otherwise the pointer out of reinterpret_cast got a value "pointer to std::byte"

[@bmazi]

It's not needed since reusing memory from std::byte array is a blessed operation (if I got it correctly). Question about launder necessity is also mentioned in q&a.

[@the-bgrspot6997]

Excellent talk :)

[@meteor8076]

very interesting, thanks !

[@WndSks]

I don't understand why it is so hard to just let people cast to another type in situations when they need/want. And if the compiler cannot optimize potential aliasing or whatever, so be it. Give us forceinterpret_cast! On Windows for example, the function GetVersionEx can take two different types as input and for the last 25 years people have been casting and just assuming the compiler does not do something silly.

[@UrSoMeanBoss]

The reason for this is because we're operating on the level of the standard, and it's abstract machine. If we had guarantees about, and models of, platforms and implementations: then such as thing would be possible. Since that isn't the direction C++ has gone, the closest we can get to what you want (as of C++20) is `std::byte_cast`. It bugs me too. The reason the windows thing works is because they're operating at another level of guarantees. That behavior is undefined by the standard, but defined by their platform. That definition, however, is inexpressible in code. 'compiler magic' (or, OS magic, in that case); similar to how the Linux kernel relies on GNU extensions to define behavior the language doesn't. I find it frustrating that there's no way to express or check for these sorts of behaviors at the level of the language. At that point, you're just praying that your compiler generates something that aligns with what the OS wants (and, the compilers put in effort to ensure that it does: but there's no way to actually _know_ that)

[@_lapys]

💙

[@terragame5836]

Or you could just add volatile to all pointers)

[@destiny_02]

that makes the problem worse, as the compiler now has to load the pointer again every time it is used, so performance loss

[@eLBehmo]

that explanation of std::launder() was great!

[@treyquattro]

good talk, but top_too_tight exception was thrown

[@alexkfridges]

Lmao, harsh