Taking a Byte Out of C++ - Avoiding Punning by Starting Lifetimes - Robert Leahy - CppCon 2022
ฝัง
- เผยแพร่เมื่อ 9 ก.พ. 2025
- cppcon.org/
---
Taking a Byte Out of C++ - Avoiding Punning by Starting Lifetimes - Robert Leahy - CppCon 2022
github.com/Cpp...
Marshaling raw bytes into objects is a perennial problem in C++. Bytes may exist in memory, we may know they’re of the correct form to back a C++ object, but the abstract virtual machine says none of the desired objects exist at that location. The temptation to type pun and hope that happens to work, and continues to do so, runs strong.
What if we had start_lifetime_as? We could synthesize objects backed directly by bytes without superfluous calls to memcpy/memmove and prayers to the optimizer. What would that world look like? What sort of patterns could we use to work efficiently and correctly in that world?
This talk answers such questions against the backdrop of a database engine which makes use of this proposed functionality. Analysis will move from raw bytes, to C++ objects, to heterogeneous streams of such objects with discussion of the sharp edges at each level. End to end zero copy will be shown to be both possible and correct.
---
Robert Leahy
Robert is a graduate of the University of Victoria where he specialized in graphics, gaming, and digital geometry processing. After spending 4.5 years in full stack web development he pivoted to financial infrastructure in early 2016 and now works on next generation market data storage and retrieval mechanisms. In 2019 he became involved in the ISO C++ committee with a particular focus on library evolution.
---
Videos Filmed & Edited by Bash Films: www.BashFilms.com
TH-cam Channel Managed by Digital Medium Ltd events.digital...
#cppcon #programming #byte
A talk by Robert Leahy is always a delight to watch.
Wow... Robert is a Fantastic presenter!!
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
I just discovered this talker and he’s amazingly good at explaining things with such simplicity! Absolutely suggested talk!
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!
I'm really glad to see that c++ is finally developing the tools to do true zero cost abstractions, SAFELY
The bit about returning a pointer to a T and not the pointer to an uncollapsed wave function was soo good! :))
A great and well presented talk!
"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".
Tech was certainly more interesting back then
This is by far, one of the best talk _ever_ !
this guy is an amazing public speaker, great talk
C++ - overcomplicating things every day.
First time?
Whoa! 😮 This talk was crazy impressive
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.
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.
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)
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.
this guy is so coool
This is a great and to the point talk!
I love this guy
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?
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.
..like he's narrating an audio book 😆
Interesting style!
Brilliant talk. We may see a readable vector implementation after all.
Thank you for the awesome talk sir
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?
Excellent talk :)
great talk, thank you.
that explanation of std::launder() was great!
very interesting, thanks !
in your start_lifetime_as function you missed std::launder, otherwise the pointer out of reinterpret_cast got a value "pointer to std::byte"
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.
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.
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)
💙
Or you could just add volatile to all pointers)
that makes the problem worse, as the compiler now has to load the pointer again every time it is used, so performance loss
good talk, but top_too_tight exception was thrown
Lmao, harsh