Observations about the C++ Standard library

[@tourdesource]

Reading STL code is like staring into the Matrix ─ only you guys could possibly make the experience enjoyable. Thank you!

[@LukaszGwizdz]

Please correct me if I'm wrong, but... As far as I know, std::launder() is necessary if a new object is created at the storage location which the original object occupied ONLY if the type of the original object was const-qualified or contained non-static data members whose types were const-qualified or they were reference types. Otherwise, a pointer (without std::launder(ptr)) to the original object can be used to refer to the new object. And it was introduced in C++17, not C++20.

[@CopperSpice]

In our example where the object being created is a Widget you would need to know the full implementation of this class to bypass std::launder and not have UB. Every data member of Widget must be non-const, not a reference, and a few other requirements. This may not be something you would know or could be guaranteed to remain true. The standard library code we showed is a template and you can not make any assumptions about what the T contains. It is simply too dangerous to make guesses like this.

[@neoprout]

As ai understand std::launder, its uses are to tell the compiler that an object name, reference, or non static data member could refer to a stale object, in which case std::launder needs to be applied on this name to force the compiler to drop any cached value and do a 'real' access. For modifiable objects or subobjects, the compiler always assumes an object name or reference may have become stale, so std::launder is not necessary when accessing the object through that name. For const qualified names (of trivial types, I think) and reference data members, the compiler always assume that their value never change (at least, using conventional ways like a builtin assignment), but it could still done by reusing the storage, or by starting the lifetime of a new object in the same storage (by use of a placement new or changing the active member of a union); this is in this very precise case that a launder on the object name or reference is necessary. Note that, since dynamic allocation of references is impossible, and that dynamic allocation of const qualified memory usually never occurs (partly because the Allocator requirement forbids any cv qualifiers, hence there is no container with a const value_type), I would expect that STL containers or allocator implementation would never need to call std::launder on a freshly placement-constructed object of type value_type (although this could occur sometimes on the key_type of some assoc container).

[@neoprout]

But casting from a void pointer, I pretty much think the compiler is required to do a full fetch on the Widget object, even if the pointer itself would be const qualified (making std::launder redundant). If we think about this, since a void pointer cannot be dereferenced and read directly, how could one keep a cached value of a yet to come static cast to a not yet know type. The compiler can't predict if the placed Widget would be in its lifetime at the very next static cast from the void pointer, or if it would be ended and another object type is placed there by the time we do a static cast from the void pointer; so the compiler cannot establish type based lifetime related relationships between the placement new expression that creates the Widget and very next expression that will access this object through that void pointer, hence it cannot cache the result of the placement new and return this cached value as the result of the static cast. Instead, it must treat the result of the static cast as an unrelated Widget from the one created in line A. Hence making launder redundant.

[@cpp1158]

Great work , please continue 🤗

[@Bob-zg2zf]

two months have passed. next video pleaaaaaaaaaz!

[@CopperSpice]

Funny you should ask, we have a new video coming out next week!

[@Bob-zg2zf]

@@CopperSpice 😍

[@notebook2866]

ok but is LGPL forbidden to be linked statically?

[@CopperSpice]

The license of your application is not tied to the C++ Standard Library. Your application can be linked statically with a third party library which has an LGPL license provided you release the source code for any changes in the library and the object files for your application.

[@jackh4158]

Thanks! Very interesting :)

[@IllumTheMessage]

Well done.