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