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