The C++20 object and memory model has no support for memory allocated from, or managed by, elsewhere to the currently running C++ program. This makes it impossible to legally write a dynamic memory allocator which uses memory not available to the C++ program when it began life, so global operator new in every hosted C++ implementation today relies on undefined behaviour. For similar reasons, shared memory, memory mapped files, or even virtual memory, cannot be legally used in C++ programs without relying on undefined or unspecified behaviour. P0593 Implicit creation of objects for low-level object manipulation "solves" this by enabling the C++ program to tell the compiler "trust me, I’m the programmer", which is a useful stop-gap, but it leaves one wanting for something better.
This talk will recap the C++20 object and memory model, illustrating the mismatch between reality on the ground for the programmer for over twenty years, and the C++ programming language. We will look at the next generation of storage devices which directly expose to the host computer the on-device internal filing system (e.g. the Samsung KV-SSD), such that i/o is exclusively key-value load and store operations, rather than reads and writes of bytes. We shall muse on how a future C++ object and memory model might be adjusted to more closely match hardware and kernel reality.
Advertisement
