Re: [boost] Serialization support

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2007-05-05 15:41:05

JOAQUIN LOPEZ MU?Z wrote:
> De: Rene Rivera
>> JOAQUIN LOPEZ MU?Z wrote:
>>
>>> Ok now I understand, and basically share, your concerns
>>> about the lack of documentation on what goes into the serialization
>>> stream.
>> I'm not sure you see the full scope of what Peter is raising, or 
>> perhaps  I'm reading more into it :-) It is not enough to document
>> the serialization for, nor the serialization procedure, as that
>> leaves out non-Boost Serialization implementations.
> 
> Well the idea is, you can leverage the B.S interface to add
> yout non-Boost serialization support. As its crudest, you
> can do the following:
> 
>   void non_boost_save(const T& t,non_boost_archive& a)
>   {
>     std::ostringstream oss;
>     {
>       boost::archive::text_oarchive oa(oss);
>       oa<<t;
>     }
>     a.save(os.str());
>   }
> 
> Something more sensible could be done by defining your
> own utility B.S Archive class, you get the idea.

Yes, I'm familiar with the idea. Your example of course is still using 
B-S. The point of my use case is that my idea of serialization may be 
very different from both the B-S idea, and the B-MI idea of 
serialization. For example I may be willing to loose some data, or I may 
want to serialize as a different structural representation.

>> I happen to have one of those non-Boost implementations,
>> and it's implemented non-intrusively. In  thinking about
>> the scope of designing a serializable class, I consider
>> the case of writing an external copy algorithm. If I
>> can't write a copy function that given one instance will
>> create an equivalent instance, then the class isn't
>> usefully serializable. 
> 
> Here you lost me. I know you're not referring to the following,
> but from your description looks like you're asking for
> a function
> 
>   T create_copy(const T& t)
>   {
>     return t;
>   }
> 
> which of course is readily available whenever T is
> copy-constructible.

Not what I was referring to at all... As that just forward the copy to 
the internal implementation ;-) What I was referring to is an 
"equivalent copy", where equivalent is use case dependent. For example, 
AFAICR, all std containers have the property that they can be 
reinterpreted as a different container (within the limits of impedance 
between the containers) by only using the public interfaces. The kind of 
copy I'm taking about is minimally seen with:

tuple< int, shared_array<int> > create_copy(vector<int> const & v)
{
   tuple< int, shared_array<int> > result(v.size(),
     new int[v.size]);
   std::copy(v.begin(),v.end(),result.get<1>().get());
   return result;
}

The result of that function is an equivalent container to the vector 
passed. It has the same information, in the same order, but not with the 
same interface.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo