Emil Dotchevski wrote:
There is another problem as well: it is useful to be able to have a function which registers classes to be serialized, then serializes them, then frees all the memory taken by the registration (this is a separate issue, but being able to unregister also allows unloading of dynamic libraries.)
The current library provides a conforming method to "register" serialization types on an archive by archive basis. For their own reasons, many users have preferred the CLASS_EXPORT method with its attendant issues. Its really an issue with the way the user has chosen to use the library rather than the library itself.
So why not allocate the object that stores the registration state dynamically? For example, provide a factory function: shared_ptr
create_serialization_class_registry(). Of course, the user is free to store the returned shared_ptr globally if that suits their taste.
As I understand this suggestion, I see no conflict with the current library if someone wants to do this. Robert Ramey