Robert Ramey wrote:
signature
All the above discussion is really a discussion about what the assignment of an object that has a const member means.  Well, in C++, it really doesn't make sense and I agree.

That's why I believe there's some tiny piece missing from the serialization library.  We should also be able to unserialize instances through a factory that returns an actual object rather than having to use operator>>.

Here's some code showing this idea that works along with the previous example.
 
...
 
I don't think this adds anytihing of value. 
 
Robert Ramey

Well, restoring objects using some sort of factory would give us a proper mechanism to restore objects with non default constructors or const members that haven't been serialized through pointers.  That would be one way to overcome the assignment like limitation of restoring through operator>>.  I believe the idea of a factory also holds well to restore objects serialized through pointers where the objects have to actually be reconstructed.

Also, fully restoring all members of an object without a default constructor currently implies writing a different serialize function depending if we are to serialize through pointers only, or directly as well: the members needed to reconstruct are either omitted or not.  This makes me believe the support for serializing through pointers is somewhat incongruous to the one for serializing directly.  It would be possible to correct this by doing something like always having save_construct_data called, and by using load_construct_data in the factory.  Something along those lines is seems to be already done when serializing and unserializing such objects from STL containers.

Thank you for your support and the serialization library; It really is a useful piece of software!

Martin