Boost logo

Boost :

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

> De: Rene Rivera
>>> 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;
> }
> }
> 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]);
   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. -
-- rrivera/ - grafik/
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Boost list run by bdawes at, gregod at, cpdaniel at, john at