Re:[boost] Serialization Library: review

From: Robert Ramey (ramey_at_[hidden])
Date: 2002-11-30 15:05:28

From: "Gennadiy Rozental" <gennadiy.rozental_at_[hidden]>

I am still considering aspects of your review. I have a questions about
a couple of comments:

>Major [Issue 2]: I believe it design error to couple both sides of
>serialization together in one library. It should be separated . So that user
>should be able to use only required part. It's not only eliminate not
>required dependency, but also make code much more clear and easier to
>navigate and  compiled code smaller.

>Major [Issue 4]: Second even if I do use vector I
>should include <boost/serialization/vector.hpp>. The same with any other STL
>data structure (only some of them are supported currently, while should be
>all). IOW serialization library will need to repeat the structure of STL
>(header-wise). And users of the library will need to include appropriate
>header.

In general I like this idea.  However, its not clear how far this idea should be 
taken.  Taken to extreme we would have:

archive concept
===========
archive.hpp - maybe includes serialization.hpp 
basic_iarchive.hpp - includes archive.hpp, serialization_load_imp.hpp
basic_iarchive.hpp - includes archive.hpp, serialization_save_imp.hpp
iarchive.hpp - includes basic_iarchive.hpp, serialization_load_imp.hpp
oarchive.hpp - includes basic_iarchive.hpp, serialization_save_imp.hpp
biarchive.hpp - includes basic_iarchive.hpp, serialization_load_imp.hpp
boarchive.hpp - includes basic_iarchive.hpp, serialization_save_imp.hpp

serialization concept
===============
serialization.hpp 
serialization_save_imp.hpp - includes serialization.hpp
serialization_load imp.hpp - includes serialization.hpp

and a directory structure that would look like:

boost
        archive.hpp
        basic_iarchive.hpp
        basic_iarchive.hpp
        iarchive.hpp
        oarchive.hpp
        biarchive.hpp
        boarchive.hpp
        ... other archives ?
        /serialization
                serialization.hpp 
                serialization_save_imp.hpp
                serialization_load imp.hpp
                vector_save.hpp
                vector_load.hpp
                ...

this minimises file inclusion and dependency but I wonder if it doesn't compromise
transparency.

The following questions arise
a)the vector_save/vector_load as is particularly annoying.  It breaks the analogy
with the standard headers <vector> etc.  However to maintain brain saving
analogy with standard libraries w would use
        /serialization
                ...
                vector
                set
                ...
(note the absence of *.hpp) and be back to combining input/output in one file.
b) the standard library combines file input and output in the same file fstream
Again, its appealing to maintain the analogy with the standard library but
it ends up putting input/output in the same file.
c) I expect that someone might want to include a portable binary archive, 
or xml archive or?.  Isn't easier to keep track of things if it all (input and
output fit in the same header file.

Generally, unless there is a compelling reason to the contrary, I prefer
to leverage on established patterns when possible in order to save
capacity.  But this conflicts with minimal dependency/inclusion

I should enphasize that this isn't really a large issue implementation wise
its just as easy to do it one way as another.  It doesn't affect anything
but ease of use and general utility (compilation speed etc).

Would you (or anyone else) like to comment (again) on this issue?

>Library should be using following namespaces:

>boost:
>basic_..achive family only. The only part of public user interface

>boost::serialization
>struct traits (currently serialization class), used by used supply UDT
>sterilization traits

So serializable classes would use ?

class A
{
        friend class boost::serialization::traits<A>;
};

and non intrusive serialization would look like

template<>
void boost::serialization::traits<A>save(boost::basic_oarchive & ar, const A1 & a1)

which would be fine with me - except for:
b) I don't believe any compilers support the above syntax for template
specialization.  In my reference (Stroustrup, The C++ programming Language),
it is only used in the context of function implemention not templates.  MSVC
required that I use the following:

namespace boost {
namespace serialization {

void traits<A>save(boost::basic_oarchive & ar, const A1 & a1)

}} // boost::serialization

which is OK but but not what I would have preferred and/or expected.

a) The word traits suggests something entirely dfferent to me. When I see that
word it makes me think a class used as a template argument.  I would be much
more comfortable with boost::serialization::implementation<A>

Anyone want to way in on this?

>rest of the code including void cast (which is better be named runtime_cast
>cause the name should emphasize not void part but namely dynamic runtime
>essence of it)

In my view, runtime_cast evokes no idea what it actually does which alters
a void pointer from one part of an obect to another part of the same object.

I was also "burned" by the movement of "is_polymorphic" from the python
libray to its appropriate place in the type_traits library.  I really see this
as belonging somewhere else as its not specific to archives nor
serialization. 

Anybody have any ideas on this?

>Accordingly directory structure should reflect this: archive.hpp should be
>the only header  under boost. Rest under serialization and
>serialization/details directories

I very much want to break binary_archive, text_archive, etc out of archive.hpp.
Aside from dependency issues it would help clarify that these are not really
part of the core of the library but rather the most obvious and common 
instances of its usage.  So I'm sort of partial to a directory structure

boost
        /archive
                archive.hpp
                iarchvive.hpp
                oarchive.hpp
                ...
        / serialization
                ...
so that users would use
#include <boost/archive/iarchive.hpp>
#include <boost/archive/oarchive.hpp>

or maybe
#include <boost/archive/text_archive.hpp>

if input/output were not separated.

Robert Ramey
if input a