Re: Persistence Library Needed in Boost?

From: quendezus (quendez_at_[hidden])
Date: 2002-02-08 11:22:33

--- In boost_at_y..., Emily Winch <emily_at_b...> wrote:
> 
> > See below a pseudocode of a mechanism to switch between compile 
time
> > and run time serialization. The compile time code is executed if a
> > terminal type is given to serialize_object( ). The run time code 
is
> > executed if a base polymorphic type is given (and 'object' points 
on
> > a derived type). Somehow, the user can thus choose the mechanism 
he
> > wants to use through the type of the parameter. Does it 
correspond to
> > your initial idea of "turn that off" ?
> 
> [ snipped code ]
> 
> I was thinking something like this (scribbled psuedocode):
> 
> enum poly_style { static_poly, dynamic_poly };
> 
> template<typename E, poly_style poly> 
> E* deserialise_object(stream& src){
>   IF< poly = static_poly,
>       static_deserialise<E>,
>       dynamic_deserialise<E> 
>     >::type()(src);
> }
> 
> template<typename E>
> E* static_deserialise(stream& src){
> 
>   // Read the object's type name
>   std::string type_name;
>   src >> type_name; 
> 	
>   // maybe we assert that the typename corresponds to typeid(E).name
()
> 
>   E* object = new E;
>   src >> *object;
>   return object;
> }
>       
> template<typename E>
> E* dynamic_deserialise(stream& src){
> 
>   // Read the object's type name
>   std::string type_name;
>   src >> type_name; 
> 
>   E* object = factory.create< E >( type_name );
> 
>   // Get the serializer for the final type
>   serializer& s = get_serializer( type_name );
> 
>   // Deserialize the object (virtual method
>   // of class 'serializer')
>   s.deserialize( src, dynamic_cast< void* >( &object ) );
> 
>   return object;
> }
> 
> ... and similarly for the serialisation code
> The format written by the static_poly code needs to be readable by 
the
> dynamic_poly code. 
> This way you don't even need to build the dynamic_poly code if you 
aren't
> using it at the moment. 
> 

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.

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 ?
2- dynamic and static case are handled, but automatically (for 
example, the dynamic mechanism is turned on for a type by the use of 
the macro that registers this type into the factory).

What do you think ?

Sylvain