named_thin_pointer<T...>

A named_thin_pointer is just a thin_pointer, but things with 'names' in this framework are also always things that can will be serialized even if they reside on the stack.

The 'name' part suggests the number (a std::size_t) which gets stored along with a plain thin_pointer. The number should be unique, as it is to refer to the pointed-to address, to the location where an object of type T resides. In the receiving client program (possibly the same binary file as from origin) the object with the same number can be retrieved automatically when deserializing some data. As soon as the data is deserialized, any named_thin_pointer with the same serialized number currently existing will receive the deserialized address to what was serialized before. If at the time of deserialization there is no such named_thin_pointer, but such a named_thin_pointer is constructed later with a number that was in the serialization, it will retrieve the correct address at construction time instead.

GrimoireGrimoire
The book is always better.
>

msg_named_thin_pointer<T...>

Adding a msg_ prefix means the type (or types) used to instantiate this template will be stored in the serialization of this msg_named_thin_pointer object. The types need to be registered to be able to correctly retrieve the type at deserialization time.

A msg_named_thin_pointer of exactly as many times void as there were type parameters expected to have been sent, in correspondence to a known numeric identifier, can be constructed, and the method 'get_type' can be queried to get the number (in the serial_context, which is the used register_types<> ordering) of the type or types which is or are stored.

<