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>. Robert Ramey wrote
I think I understand the question - maybe. As the library is written, the inquiry into the the type of object is part of the loading process and off hand I don't see how one could "look ahead" without actually loading the object.
You might be able to write some code which would "look ahead" but I have no idea what it would entail.
why do you want to do this? What is the context?
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. Nicolas. -- View this message in context: http://boost.2283326.n4.nabble.com/serialization-how-to-retreive-true-type-f... Sent from the Boost - Dev mailing list archive at Nabble.com.