Re: [Boost-users] Using boost::serialization inreal-timewithoutallocating memory

Am Monday 21 September 2009 19:10:15 schrieb Robert Ramey:

Peter Soetens wrote:

...

On Fri, Sep 18, 2009 at 23:56, Robert Ramey wrote:

...

Peter Soetens wrote:

...

...

That's it ! I used the wrong load/save functions. I cleaned up the archives and documented a bit. The only obscurity is that both classes required a 'save/load_object()' function, while this is not documented as such in the Archive Concept pages. Is this a recent addition (I'm using Boost 1.37.0 btw)

This would be due to the fact that even the "trivial_archive" inherits functionality from common_?archive. The archive concept doesn't require this - but most archives will want to do this - then override the implementation of common_?archive.

That's not my point. As I understand the 'Loading/Storing Archive Concept', any archive that implements the listed functions should be able to process 'ar << data;' if the serialization handler for data is defined. My archive implemented the concept fully, but did not compile because of a missing function. The only conclusion I can make is that the concept is not complete, or violated because people only tested it with the common base class and started to assume some functions were there while they are not required to be.

I would have to look into this in more detail to really provide an answer. Clearly, the fact that that "trivial_archive" inherits from common_archive would suggest you're correct about this or maybe that something else is out of whack. I'll look into it when I have nothing else to do. Given you've already wrapped your head around this whole issue - maybe you want to suggest how something might be changed. My first approach would be to figure out why save/load object is required to compile. Perhaps this is just an implementation artifact. Ideally the implementation could be slightly refactored to support the original concept.

I think to support this an other use cases like it common_archive would have to be moved outside of the linked library into a header and be made more generic. right now it's full-blown type-registering/object-tracking, object-graph with class-hierarchy serialization, or nothing - write your own archive from scratch. I've also had my problems with that. although I didn't have to avoid allocation completely, the construction of a common_archive took too long and you couldn't configure away the parts you don't need. such a generalization could be based e.g. on what is described as "levels of sophistication" of serialization, here: http://www.parashift.com/c%2B%2B-faq-lite/serialization.html#faq-36.2