3 ms·
> This separates construction, which is a typed thing, from allocation. But this is what C++ actually does! C++ ctors run after memory has been allocated (on t
by spacechild1 4y ago
> This separates construction, which is a typed thing, from allocation.
But this is what C++ actually does! C++ ctors run after memory has been allocated (on the stack, on the heap, from a pool, etc.) Or maybe you mean something different?
- Animats 4y agoThe lifetime of the space can be different, but must enclose, the objects created in that space. C++ doesn't track lifetimes. Such a separation is only useful in specific situations, such as the one the original article mentions. It could be useful in avionics or industrial control, where you often avoid memory pools and have arrays of specific kinds of objects instead.
- pjmlp 4y agoDepends on what kind of lifetimes, yes C++ doesn't do Rust like lifetimes check, at least not without help from static analysis. However C++23 has introduced compiler aware functions to start specific lifetimes out of raw memory pools. https://en.cppreference.com/w/cpp/language/lifetime https://en.cppreference.com/w/cpp/language/lifetime
- spacechild1 4y agoIf you mean std::launder, this has been around since C++17. (Not that I ever had to use it :-)
- pjmlp 4y agohttps://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2590r2.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p25...
- spacechild1 4y agoThanks for the link! I got confused because your cppreference link only talks about std::launder. I did not know about std::start_lifetime_as. Looks very useful! It's crazy that it took so long. Considering that one of the primary design goals of C++ was backwards compatibility with C (too a large extent), I always found it crazy that malloc'ing objects would be undefined behavior. In practice, this has always worked, though. At least now we have a standard-blessed way to do these kind of things. As a side note, does this mean that you can finally cast an array of bytes to an object pointer (e.g. for deserialization) without violating strict-aliasing rules? The usage example in section 1.2 of the linked paper seems to imply this, but it does not mention aliasing anywhere...
- pjmlp 4y agoI guess this is also interesting to watch, "Taking a Byte Out of C++ - Avoiding Punning by Starting Lifetimes - CppCon 2022" https://www.youtube.com/watch?v=pbkQG09grFw https://www.youtube.com/watch?v=pbkQG09grFw
- spacechild1 4y ago> C++ doesn't track lifetimes. Of course, C++ does not have lifetimes (in the Rust sense), but your original claim was that C++ does not seperate allocation from construction. > Such a separation is only useful in specific situations, such as the one the original article mentions. It is actually quite common. You don't even have to reach for advanced things like memory/object pools. For example, if you want to implement a dynamically sized array type (std::vector), you typically want to increase the storage independently from the number of objects. But then again, maybe you are talking about something different here... --- Also, I may need to clarify some things about C++ allocators. They are not used to allocate storage for the object itself, but rather control how an object allocates memory for its subobjects. Keep in mind that the object itself may exist in a different kind of storage than its subobjects. For example, the object may live on the stack, but its subobjects must be allocated dynamically.
- spacechild1 4y agoEDIT > but your original claim was that C++ does not seperate allocation from construction. At least that's how I interpreted it.