[boost] Re: Re:Serialization Library: review

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2002-11-30 16:56:35

"Robert Ramey" <ramey_at_[hidden]> wrote in message
news:01C29868.C6837580_at_226-146.adsl2.netlojix.net...
> 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 ?

ioarchive.hpp

> /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.

Yes I believe we could combine input/output algorithms for stl constructs.
In any case it should be simple template functor that wont be instantiated
if not used.
But I would prefer:
/boost/seralization/stl/
vector.hpp
list.hpp
....

> 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.

You could provide ioarchive.hpp that will include both input/output

> 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?

In my expirience pack/unpack differ significantly cause may solve problems
of different nature. In first case it's may include algorithms for detecting
best compression, or it could be very simple visiting algorithm. Unpack side
on the other hand may include input analizing, pattern matching or memory
management issues. They could have shared part that could always be factored
in common header.

> 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.

It looks ok for me. Nor "traits" nor "serizlization"  could not be part of
global namespace. SInce you need one boost::serialization good choise for
me.

> 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>

Traits is NEVER a template parameter. Policy is. Traits are always refer to
the *type specific* logic. While Policy refer to the logic that is
orthogonal to the "main" type.
numeric_limits is trait cause for every type there could not be more than
one possible value for maximum type value. ThreadingPolicy is Policy cause
the same smart pointer you could use in single or multithreaded enviroment.

>
> 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 am not actually sure it should work on void pointers at all. What if type
information is stored in the pointer and your cast need it? Instead of
type_info that IMO should be generalized (see issue 1)

> 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>

#include <boost/ioarchive.hpp>

> or maybe
> #include <boost/archive/text_archive.hpp>
>
> if input/output were not separated.
>
> Robert Ramey

Gennadiy