Boost logo

Boost :

From: quendezus (quendez_at_[hidden])
Date: 2002-02-28 04:47:54

--- In boost_at_y..., Vladimir Prus <ghost_at_c...> wrote:
> I have the following comments:
> 1. It would be much better to stick to the scheme with one function
> 'desciribe'. This would allow to reduce code size needed to make an
> serializable, and will also allow using the same 'describe'
function with
> other classes. Is there any problems that I've missed? (but see
point 4 below)
> ...
> 4. Versioning is completely omitted from documentation. How does it
work? Can
> I disable it completely? Oh... and now I sense some problem
with 'describe'
> method -- it will have to describe specified version of a file. And
what to
> do with member variables with were added in the last
version? 'load' version
> can contain arbitray logic to set their values. 'describe' will
have no way
> to do it, so we'll have to either rely on defaul-initialization to
be ok, or
> provide and additional function which does 'fixup' after a old
version of
> class was loaded.
> - Volodya

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> ----- Original Message -----
> From: "Peter Dimov" <pdimov_at_m...>
> If you're willing to require a default constructor, shouldn't you
also find
> a way to describe the type once so you don't have to code a reader
and a
> writer that look nearly identical?
> -Dave

I don't think the 'describe' scheme is good. Volodya noticed a
problem with member variables added in a late version, but the
problem is more general. See the example below :

struct file
        std::string fileName_;
        FILE* f_;

        file( const std::string& fileName ) : fileName_( fileName )
                f_ = fopen( fileName.c_str(), "rb" );

void save( archive& a, const file& f )
        a << f.fileName_;

void load( archive& a, const file& f )
        a >> f.fileName_;
        f.f_ = fopen( f.fileName_.c_str(), "rb" );

I consider the load function as a constructor that takes its
parameters from the archive (that is why it seems odd to me to
imagine a deserialization on an object not built with its default
constructor). In the load function you sometimes need some code (fopen
( ) in my example), exactly like in a constructor.

Moreover, the 'describe' scheme implies a symetrical management of
the serialization/deserialization, that I have rarely seen in real
life code. On the load side you can have validation code, debug code,
etc. In the save side you can have parsing of the serialized data to
see which one to keep given the state of the program, etc.


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