Taking a Byte Out of C++ - Avoiding Punning by Starting Lifetimes - Robert Leahy - CppCon 2022
Vložit
- čas přidán 28. 10. 2022
- cppcon.org/
---
Taking a Byte Out of C++ - Avoiding Punning by Starting Lifetimes - Robert Leahy - CppCon 2022
github.com/CppCon/CppCon2022
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
CZcams Channel Managed by Digital Medium Ltd events.digital-medium.co.uk
#cppcon #programming #byte - Věda a technologie
A talk by Robert Leahy is always a delight to watch.
I'm really glad to see that c++ is finally developing the tools to do true zero cost abstractions, SAFELY
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
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!
The bit about returning a pointer to a T and not the pointer to an uncollapsed wave function was soo good! :))
"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
I just discovered this talker and he’s amazingly good at explaining things with such simplicity! Absolutely suggested talk!
A great and well presented talk!
this guy is an amazing public speaker, great talk
This is by far, one of the best talk _ever_ !
C++ - overcomplicating things every day.
First time?
I have feeling that new C++ "features" solves problems which simply even does not exits in other languages 🙂
Whoa! 😮 This talk was crazy impressive
Thank you for the awesome talk sir
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)
This is a great and to the point talk!
great talk, thank you.
Excellent talk :)
I love this guy
Brilliant talk. We may see a readable vector implementation after all.
very interesting, thanks !
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.
that explanation of std::launder() was great!
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.
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!
in your start_lifetime_as function you missed std::launder, otherwise the pointer out of reinterpret_cast got a value "pointer to std::byte"
💙
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?
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)
This is such a backwards problem. I think the abstract machine was a mistake.
I don't think you know what you're talking about at all
good talk, but top_too_tight exception was thrown
Lmao, harsh