nico wrote:
Thanks for your answer Robert .
I answer some of your remarks / questions :
Robert Ramey wrote
I don't see that this practice is necessary. I'm not sure it's desirable either. The serialization library goes to great lengths to make this unnecessary. Having said that, I don't know that there's anything wrong with it. It's off topic - but just thought I'd mention it.
Indeed this is not the way the library is supposed to be used, I guess. But I work with a team of about 15 developers, and it had been a pain to maintain our set of serialized objects. One saved a pointer to Image object in an archive, another try to load it to a shared_ptr<Image> in a test. One saved a sharerd_ptr<Image> in the application, and a tool ImageViewer expect to deserialize an Image... And so on...
So obviously we must take care about the type serialized. But in fact it has really been a bag of hurt, and just asking to use shared_pointer for instance for all serialization stuff was not enough! Finally with a set of rules to respect when we make a class serializable it simplified our daily. A serializable class must virtually publicly inherit from a base class ISerializable which declares SaveToFile and LoadFromFile and all objects (of class C) are serialized as C*, and the deserialization returns a shared_ptr<C>.
Hmmm, wouldn't the same result of getting everyone on the same page be obtained just by requiring intrusive serialization without the requirement of a common base class? In other words, I think the same result could have been obtained by prohibiting non-obtrusive serialization within your group. Actually, this is pretty much equivalent to what using a common base class does. It's not that I'm critcising the practice but I'm just trying to understand it. One of the goals of the serialization library is to ecapsulate the method of serialization into each type so that it is always carried from application to application along with the other type implementation code.
Here my purpose is our product upgrade. The backward compatibility is mainly ensured with the boost serialization class version management. But in rare occasions, the class structure can change and so we can't deserialize old archive. In that cases the backward compatibility is ensure by executables we provide with the upgrader, and they transform our archives. And I'm trying to get the name of the true_type in the archive to retrieve the executable : it has the same name. I guess it's possible, as the boost archive code itself can instantiate an object of true_type when deserialization is done.
so what you'd like is someting like if( ar.next_type == ?) ar >> t; I see this as hard to implement even from within the library. Now if you had serialized your objects as ar & boost::optional(t) Then you'd be done. Of course you might need a time machine. Robert Ramey
Nicolas.