Re: Persistence Library Needed in Boost?

From: quendezus (quendez_at_[hidden])
Date: 2002-02-11 05:39:58

--- In boost_at_y..., Emily Winch <emily_at_b...> wrote:
> 
> Sylvain wrote:
> 
> [ my example of choosing between static and dynamic polymorphism 
> at compile time ]
> 
> > I see. But how does the user choose one way or the other ? If
> > suddenly a type is no more accessible at compile time (header 
split,
> > etc.), the user has to change his code from static_poly to
> > dynamic_poly in all the places instances of the type were beeing
> > serialized.
> 
> Then the user needs another layer of abstraction, to make sure the 
> decision is only made in one place.
> 
> > I would prefer one of the following scenarii:
> > 1- Only the dynamic case is taken into account. After all, if the
> > dynamic case works, why bother with the static case ?
> 
> I'd like to be able to do something a bit like
> 
> typedef typelist<foo, bar, baz, haddock> list_type;
> tuple<list_type> t = /* something */;
> serialise(t, stream);
> // ...
> deserialise(t, stream);
> 

The first problem I see is in the line :

   tuple<list_type> t = /* something */;

If 'haddock' is a pointer on a base class, and 'something' contains a 
pointer on a derived class, I think the static serialization will not 
work correctly. The best thing the framework could do is to assert at 
run time: assert( typeid( E ) == typeid ( *p ) ). To solve this 
problem, maybe the user would anyway prefer the dynamic mechanism, 
even when the types are known at compile time.

>
> and not have to build into my code a bunch of stuff designed for 
> more heavyweight serialisation than I need. 
>

The overhead should not be too big, or this will not be accepted in 
boost :o)

>
> Nevertheless I'd like
> to be able to write
> 
> std::vector<variant<list_type> > v;
> deserialise(v, stream);
>
> in some cases where I need that kind of behaviour.
>

If you want class A to use the static mechanism for serialization and 
the dynamic one for deserialization, you will not be able to put the 
DECLARE_SERIAL( A ) macro (or whatever declarative syntax that 
registers the class) in the header file of the class. I know this 
should not be a problem (even an advantage) for a non intrusive 
system, but I think it is a common habbit, because in many case this 
is simpler and clearer. So most of the time, maybe the user will 
anyway have the (not so) heavyweight serialisation code built into 
the project, even when using the static mechanism.

> 
> I'm not suggesting that anyone else necessarily wants to do
> this, maybe it's only me :)
> 

I also often know types at compile time for serialization but not for 
deserialization. So I mostly agree with you. But at the moment, I 
think the drawbacks of a static/dynamic serialization mechanism 
(harder to code and maintain, harder to use) do not counterbalance 
the drawback of an only dynamic system (code size overhead in some 
situations).

Sylvain