(no subject)

From: rameysb (ramey_at_[hidden])
Date: 2002-02-28 13:20:00

Permit me to attempt to summarize the recent discussion:

I have attempted to distill the points made in the recent
discussions to the basic issues.  If I have mischaracterized
someone else's concern and/or arguments, I apologize - believe
its purely unintentional.

Consensus
=========
I believe there is wide agreement on this aspects of the system.

a) usage of term "serialization" rather than "persistence" to 
ddescribe what this package does - no objection registered so far
b) implementation of archives in terms of istream/ostream. no 
registered objections.
c) usage of << and >> overloaded operators for iarchive and 
oarchive. -most people seem comfortable with this.
d) serialization of pointers is a useful thing even though it can 
lead to some extra difficulty.

Design issues
=============
a) save/restore of const members and references
   i) These can only be set during construction.
   ii) serialization can be characterised as saving an restoration
       of an object's state.  since these members aren't mutable
       they shouldn't be subject to serialization.

   The view has been expressed that this system should be able 
   restore const and reference member variables.

   Case of non-pointer serialization
   =================================
   I strongly disagree with this view point.  In my view these values
   are by definition immutable and not part of an objects mutable
   state.  To declare a variable const then have serialization
   change it would be a violation of the whole idea of a const
   member in the first place. (not to mention implementation issues)
   Basically, the serialization mutates an object to some previous
   state. Immutable aspects of the state are just that and should not
   be subject to alteration via serialization or other means.

   Case of serialization through a pointer
   =======================================
   This is less clear.  In any case I believe that all points of view
   are accomodated by the discussion of b) below.

b) Requirement for default constructor and related issues
   For objects serialized through a pointer, the library 
   implementation of object creation requires that the serializable
   class have a default constructor. I believe that this is a
   necessary and reasonable requirement.  However, If an application
   is such that this is a burdensome requirement or creates
   some other conflict then usage of this aspect of the library would
   have to  be avoided for the particular class.  How to do this is
   illustrated by the following example:

The most common and obvious way of deserialzing a through a pointer
is illustrated by the followin snippet.

class B
{
        int x;
        void load(iarchive &ar, int file_version)
        {
                ar >> x;
        }
        void save(oarchive &ar) const
        {
                ar << x;
        }
        B();	// required default constructor for
                // deserializing through a pointer
}

class A
{
        B *b;
        void load(iarchive &ar, int file_version)
        {
                ar >> b;
        }
        void save(iarchive &ar) const
        {
                ar << b;
        }
};

So far so good.  Now suppose someone decides he can't use a default 
constructor for his application.  He will have to avoid using the 
automatic object creation and replace it with his own so the code 
will look like the following:

class B
{
        const int y;
        int x;
        void load(iarchive &ar, int file_version)
        {
                ar >> x;
        }
        void save(oarchive &ar) const
        {
                ar << x;
        }
        B(int _y) :
                y(_y)
        {}
}

class A
{
        B *b;
        void load(iarchive &ar, int file_version)
        {
                // replace the library provided creation with your own
                int y;
                ar >> y;
                b = new B(y);
                // restore non-const stuff
                ar >> *b;
        }
        void save(oarchive &ar) const
        {
                ar << y;
                // pointer not serialized - object only
                ar << *b;
        }
}

No default constructor will be necessary. (note: code modifications 
ight be required to implement this but I believe it is possible an 
hat they would not be difficult.).

Pending implemention issues
===================
a) iarchive/oarchive private usage of stream operators << and >> may 
conflict non-portable across locales.  There might be other reasons 
not to do this. In any case it is strictly an issue with the private 
impentation of  iarchive and oarchive. This could alter the 
implementation of iarchive/oarchive but would have effect on the 
library interface for applications. I'm am looking into this.  
   
Resolved (at least in my mind) alterations
==========================================
I have concluded that the value of these modifications exceeds the
cost of thier implemention.  I do not believe there would objections
to these.

a) better checking to detect errors in serialization of pointers

b) adjustments to permit usage on compilers that don't implement
   partial ordering.

c) binary format archive
   issues - here is a summary of the binary/text archive issue
   i)  binary data is fundementally non-portable
   ii)  converting to/from text alters floating/double numbers
   iii) binary storage is considered more efficient
   
   I would propose that two new classes be created - say 
binary_iarchive
   and binary_oarchive that would use binary rather than text output.
   This would:
   i) not be very hard to do.  Only a small part of the iarchive and
      oarchive classes are particular to text/binary i/o.  These
      sections could be moved to derived classes.
   ii) It would mean that save/load functions would suffer no changes.
   iii) programs could select binary/text archives at runtime by
      choosing which variation of archive to use.

I believe that making the changes/additions described above
(under Resolved ...) would address all known issues and
concerns in way that would be acceptable to most participants.

Making these changes woudl take about a 10 days.  I'm going to defer
this until its clear to me that there is in fact enough consensus
on the pending design issues to justify the effort.

Thank you for all the feed back.  It is generally constructive,
insightful and of high quality.

Robert Ramey