Re: [boost] Serialization Draft Submission # 3 - Final Draft

From: Robert Ramey (ramey_at_[hidden])
Date: 2002-05-19 18:53:52

 >Date: Sat, 18 May 2002 18:27:20 -0400 (EDT)
 >From: Davlet Panech <davlet_panech_at_[hidden]>
 >To: boost_at_[hidden]
 >Subject: Re: [boost] Serialization Draft Submission # 3 - Final Draft

Thank you for feedback.   Its clear you have subjected the 
documentation to a fairly close reading.  This is very
helpful to me and much appreciated.

Below i address some of your concerns.  I expect to 
incorporate these clarifications in the submitted version of 
documentation.

Robert Ramey

>Also I believe there is more to portability of text
>archives than support for a particular character set
>(especially when it comes to wide characters). Two
>"platforms" might very well support Unicode but use
>different representation of characters.

archive portability for "portable archives"
=============================
i/oarchive can be used to transfer information accross platforms
under the following conditions.

1)both environents use the same character set for stream operators
>> and << applied to arithmetic types.

2)Translating character or wide character strings accross character
sets is outside the scope of this serialization library.   However,

a)character strings will be transfered across platforms without loss
of information if sizeof(char) on destination platorm >= sizeof(char) 
on source platform.

b)wide character strings will be transferred accross platforms without
loss of information  if sizeof(wchar_t) on destination platorm >= sizeof(wchar_t) 
on source platform.

3) numeric values are rendered as text and read back as text using
the stream operators << and >>.  This
will make archives portable as to numeric values as long as the destination
machine can actually handle the numeric value.  For example, if
the the machine that creates the archive uses 24 decimal digits
for floating point precision while the reading one uses only 18
then we're not going to capture the exact data on the destination
machine. Presumably the reading machine would either round,
truncate or throw an exception upon reading such a value.
Whether this results in a loss of information or not would depend
on the application.  Similar considerations apply to size of integers etc.

So what is a reasonable definition for "portable text archive"

Subject the above conditions, this system will permit
arbitrarily structures of objects to be transfered across
different platforms without loss of information.  This is a useful
and valuable facilty which will permit a large majority of datasets
to be transfered among a large majority of platforms in 
common usage today.  if the phrase "portable text archive"
is too strong so as to be misleading,  I'm open to alternative
suggestions.

>Also I think the use of term "platform" is not
>appropriate in the context it is used.

Platform
======
I used platform to include the combination of machine, OS, 
and compiler.  My interest is to specify environments that
are in some way different so as to require some special
consideration  without going into the source of the differences.
I think this is common practice. If this is a source
of confusion, I would be interested in hearing alternative
suggestion.

>- how exactly does one implement serialization not
>based on streams?

archives are derived from basic_iarchive and 
basic_oarchive.  These base classes consist of
helper functions and virtual functions which 
in no way depend upon the storage mechanism.

The derived archive classes in the library all use
stream for storage.  This is not a general requirement.
For example the native binary archive classes boarchive
and biarchive could use file stream buffers rather than
streams. Since binary files have no need for the stream
>> and << operators.  In fact It might have even
been more efficient.

One could implement an archive for save/loading 
serialized data to/from a simple byte string.  This 
could be used to send complex obects accross
remote procedure calls.  This could be useful in 
addressing one of the more annoying aspects of
COM programming.

As used here, serialization addresses the mapping of an
arbitrarliy complex object to a serial string of bits
and recovering it back again at some other time
and/or place.  This is usually but not necessarily
related to file storage.

>- there are typos :)

I'll review again, Meanwhile please feel free to send 
me a list that I might make corrections int the
documentation.

>- The "Overview" section contains the following set of
>sub-headings:

>** Archive Operators **
><text>
>** For Primitive Types **
><text>
>** For Classes **
><text>

>Headings that start with "For" in the middle of text
>left me buffled there for a while. Perhaps you should
>repeat the word "Operators" in each such phrase (e.g.,

It looked fine to me - but then I wote it and I can never see
things like this in my own stuff.  After considering you comment
I'm inclined to us:

>** Archive Operators **
><text>
>** Operators for Primitive Types **
><text>
>** Operators for Classes Types**
><text>

Robert Ramey