[boost] [serialization] basic oarchieve and common oarchieve

From: Robert Ramey (ramey_at_[hidden])
Date: 2003-10-27 20:19:44

Vladimir Prus wrote:

>I'm somewhat lost about basic oarchieve and common oarchieve classes. For 
>example, the first provides some interface in form of virtual functions. Yet 
>I don't know how to use that class, and whether it's indented to be accessed 
>by users at all.

its not intended to be used by users at all.  Its used to implement
archive book keeping (object and class id's etc) through a pimpl.  Its 
functions (there are only a few) are called only be the serialization library.

>Personally, I thought it was analoguous to basic_ostream. If a function takes 
>basic_ostream<char>*, you can pass ofstream* to it, and everything will work. 
>Before we talked with you about virtual_archieve class, I tried to use 
>basic_oarchieve as such virtual archieve class.

>I think that if no user of your library is supposed to ever directly use 
>basic_oarchieve, then maybe this class should be in "detail" namespace, 

perhaps - we can look in to this

>maybe inheritance from that class should be private, not public. 

maybe

>The same 
>question applies to common_archieve. It seems like it's implementation help, 
>but it's not marked in code as such.

common_?archive is somethine else.  Its derived from basic_?archive.  It really
has two functions

a) serves a base class for real archives.  It uses CRTP as a sort of "static virtual
base class"  So it implements common templated functions such as
register_type and soon operator &.

b) serves a link to hook the virtual functions defined in base_?archive
to the template functions that actually implement things like serialization
of object_id for a specific archive.

I was pulled in two directions:

a) the usage of virtual function interface permited me to implement a pimpl
for a lot of stuff that would never change and is really internal to the library.
This would help conceptually  isolate one of the most intricate parts ot the libary and avoid
constant re-compilation of code which never changes.

b) The usage of CRTP (Curiously recurring template pattern) to implement
"static virtual functions" that result from definition of archive templates
which can vary independently of the serialization.  This gives maximum
runtime speed and elminates the need to provide for every possible
data type apriori.

So this resulted in a layered (inheritance) design

0) basic_?archive - typical virtual bas class which permits usage of pimpl

1) common_?archive - CRTP base class for specific archives

2) general purpose user level archives - binary, text, xml, ?
The manual contains a section describing how one would go about
making a new implementation of this layer.  In includes and discusses
code for a "trivial_archive" derived from layer 1 above.  The archives
included in the system are elaborated versions of this "trivial_archive"

3) user customization of one of the archives in level 3.  Note that this is
not possible yet.  A modest change has to made in layer 2 above to support
this and I havn't had the time yet.  The manual has a section on how
to customize and archive from layer 2 via inhertitance.  Currently 
invoking this page turns up a blank page - watch this space.

I look at the above description and have to laugh.  When I describe this
it sounds very logical and deterministic.  It sounds like
I sat down and worked out a design and implemented in a logical
orderly and sequential  fashion.  

I start with sort a design - really just a set o boxes
where I put stuff that seems to go together.  I start to fill the
boxes in with code.  Some boxes get too big to understand
and I divide these into other boxes.  Sometimes I take
stuff out of boxes and put it in other ones.  Empty boxes
get thrown away.  Mostly I shuffle stuff from box to box
trying to make the boxes fit together without looking inside
them more than necessary.  Then I make the manual
and examples.  This results in lots more shuffling to make
the user interface simpler and to add code to deal with 
case that I couldn't imagine.  Finally I upload it
and someone asks a question like yours and I layout a
response like the one above.  Its not that the response is not
true - it is - its just that it suggests that the final product is the
result of some systematic, orderly procedure - which is as 
far from the truth as it can possibly be.   I don't know if anyone
else sees the irony here. oh well

Robert Ramey