Re: [Boost-users] Usingboost::serializationinreal-timewithoutallocating memory

Subject: Re: [Boost-users] Usingboost::serializationinreal-timewithoutallocating memory
From: Stefan Strasser (strasser_at_[hidden])
Date: 2009-09-21 16:26:51

Am Monday 21 September 2009 21:25:28 schrieb Robert Ramey:
>
> as I alluded to before - what I would like to know is why I derived
> trivial_archive from common_archive.  I don't remember what
> made me do this.  It seems that if this isn't done then save/load_object
> is necessary.  So the question is - why is this?  It is an oversight
> somewhere? or does the archive concept have to be changed.

common_?archive derives from basic_?archive, which implements the 
save_object/save_pointer functions: type registration and object tracking.
so if you need to serialize graphs (as opposed to trees) you have to derive 
from basic_?archive, unless you want to implement your own registration 
system.

>
> Personally, I generally don't like the "traits class" as an argument.
> It sort of implies that that the template has a lot of "if -" code
> which navigates the traits. A "policy class" is better but can
> still make things complex.
> Personally I prefer composition 
> of funtionality through inheritance.

I'm not sure if we talk about the same thing when we say "traits class". it 
does accomplish composition of functionality, just not through inheritance.

see 
http://www.boost.org/doc/libs/1_38_0/doc/html/intrusive/node_algorithms.html#intrusive.node_algorithms.circular_slist_algorithms
for an example from boost.intrusive.

the traits class isn't a configuration class, requiring if-then-else code in 
the archive class, but provides actual functionality - type registration and 
object tracking.
so it would have functions like register_object, get_object, etc.

the default argument to the traits template parameter would implement the 
current type registration and object tracknig system, using the STL maps that 
have caused trouble for some of us.
maybe that could also be inserted somewhere in the inheritance tree and a 
traits class be avoided if you prefer that. the goal in any case is to be 
able to store that object tracking/type registration information somewhere 
other than STL containers that are hardcoded in the archive base class, 
without having to reimplement serialization logic.