Hey Nat, Thanks for your reply. I think you're right. That is to say, if your expectation of boost allocating a new object - which I'd say is a fair assumption - is correct, then my way of approaching the boost serialization object is the reason for all of this headache. I'm basically using the serialization object as a means to minimize the amount of code (and therefore needed maintenance) needed to save/load data on the HD, used by my application. I've been reading a bit about, and although there seems to be a significant overhead by using boost, I have (so far) judged it to still be worth using, as the data I need to save (from the object) will only increase in complexity. Most of the data contained in my object is meta-data created from an audio source. I'm only passing some of the fields, since I only want to re-create the meta-data, I create while processing the audio source. The actual audio (which the object also contains) is read from a separate file and does not need serialization. I'm all ears for an opinion on the approach. It would just appear to me that serialization is appealing to keep the code simple and still be quite flexible. Regards, Lasse On 28-11-2012 01:23, Nat Linden wrote:
Disclaimer: I haven't used the serialization library, nor have I carefully read your code example.
I simply wonder whether your mental model of deserialization agrees with that used by Boost.Serialization. I believe (!) that when deserializing an object through a pointer, Boost.Serialization allocates a new object before filling (some of) its fields from the incoming data stream. You seem to expect Boost.Serialization to reuse an existing object in memory instead. (I hadn't previously encountered the phrase "partial serialization.")
I believe that in the typical use case addressed by Boost.Serialization, the deserializing process has no direct access to the memory data used by the serializing process. That might be because the serializing process is shutting down for later resumption, or it might be that the serializing process is running on a different machine than the deserializing process. In either case, the only object fields on which the deserializing process can rely are those that were explicitly serialized and deserialized by your code. Put differently, any fields you fail to de/serialize must be assumed to be uninitialized.
You may have an unusual use case. If you can somehow pass some of the fields of your memory object to the receiving process other than through Boost.Serialization -- may we ask why not all of them? Why are you using Boost.Serialization at all?
Apologies if I haven't properly understood your issue.