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
> > 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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk