Boost logo

Boost Users :

Subject: Re: [Boost-users] Usingboost::serializationinreal-timewithoutallocating memory
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-09-21 15:25:28


Stefan Strasser wrote:
> Am Monday 21 September 2009 20:27:59 schrieb Robert Ramey:
>> Stefan Strasser wrote:
>>> 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.
>>
>> common_archive is a template - it's not in the linked library.
>
> ok, I must have mixed up some types. the point was that the ultimate
> base class, that handles the type registration and object tracking
> etc., is
> linked .cpp and not very configurable.
> the optimum case imho would be that you could pass a traits class to
> that archive base class, that gets called whenever there is an object
> or type to be registered and is queried for existing objects and
> types later on.
> that way you could disable registration, save type registration
> outside of the archive itself, let type registration span multiple
> archives etc, make sure type registration doesn't allocate etc.

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.

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. This can be seen in
the class diagram for the serialization library. And your example
makes me more convinced than ever that this is basically
right. Now the only loose end it investigate why save/load
object is required.

Robert Ramey


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net