From: "Gennadiy Rozental" <[EMAIL PROTECTED]>
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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
