Adam Verigin wrote:

I'm working on integrating Boost serialization into an OMNeT++ simulation as a means of saving a partial simulation state (to speed up statistical testing). The problem I am running into is related to the process of deserializing a derived-class object by a base-class pointer without tracking.

As far as I can tell, in this case the serialization library normally: 1. Determines the most-derived type 2. Allocates memory for that type of object 3. Updates the pointer to point the the above allocated memory block 4. Invokes placement new and the default constructor (overloadable by load_construct_data) 5. Calls the class' serialize() or load() method on the newly-constructed object

However, I have a case where I start out with an existing derived-class object that is partially initialized, and I just want to call the serialize() or load() method for it using a base-class pointer (i.e., no memory allocation since that's already done, and no constructor call since that's also already done.) Is this possible or am I trying to do something the serialization library is not meant for?

It's not the most common scenario. It can be addressed, but requires some more complete understanding of the library. The library "just works" for the common cases. Think about why you have a base class pointer in your class which will "never change". That is, if you recover it with out re-creating it, you're assuming that in the meantime the following statement has not been executed. my_base_ptr = some_derived_ptr; That is, you're writing code on an assumption which you can't enforce. If someday, in some other code module, far, far, away .. someone executes the above, you'll have some unrecoverable mess to deal with with no clear idea of what the source of the problem is. Sooo - my suggestion is to replace struct my_thing { Base *m_ptr ... }; with struct my_thing Base &m_b ... }; This will "just work" as far as serialization is concerned. Now if making the above change in your program is hard to do, you should think about it a little bit more before you insert a booby trap into your program. Usually, this will entail some refactoring to get things back together again. But the result will be something more robust, less likely to contain bugs, easier to test and aintain. Of course if you're working in an environment whose controlling principle is "just make it work right now", you're out of luck. You'll just have to bury the bomb in your program and hope you're not in the immediate vicinity when it blows up. Robert Ramey

Thanks, Adam Verigin

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users