Re: [boost] Re: generic polyvalent input/output ['pickle']

From: Beman Dawes (beman_at_[hidden])
Date: 2000-11-17 11:06:13

At 12:05 PM 11/17/2000 +0100, Asger Alstrup Nielsen wrote:

 > ... I'm the one who suggested XTL in the context of serialization,

XTL is very interesting, thanks for suggesting that we look at it.

 >I'd be obliged if people would give an indication of whether I should
 >spent some more time and energy to try to track him down, i.e. whether
 >XTL as such (with the proper work) has a chance to be adopted into
 >boost.

Neither XTL or persistent.hpp is ready just yet for prime time, for the 
reasons noted in various prior postings.

I'd like to better understand the differences in the overall approaches, 
and see if one seems markedly superior to the other.  Then let's ask for 
volunteers to prepare a submission for formal review.

After reading the XTL docs and looking at some of the code, I can see some 
of the details, but I've having trouble seeing the big picture.  Below is a 
little diagram (with personal opinions added) I drew to better understand 
the persistent.hpp design. (I only looked at saves; loads use the same 
design.) Could you do something similar for XTL?

Thanks,

--Beman

-------------------------------

Persistent.hpp Design

// convenience wrapper for saving to a file
save_file<Writer,Container> (container, filename )
   Writer writer; // instance
   call save(writer, container)
         |
         |
         V
// sequence overloads
overload for each std library container:
   save<Writer, container parms...>(writer, container)
     calls save(writer, container.begin(), container.end())
         |
         |
         V
// sequence iteration
save<Writer, ForwardIterator>(writer, first, last)
   for first to last-1
     calls save(writer, *first)
         |
         |
         V
// object save
save<Writer,T>(writer, object)
   calls writer.write(object)
         |
         |
         V
// writer
//   supplied: shift_writer, binary_writer
//   user can supply their own writers for special formats
constructor which takes a std::ostream
default write:
   write<T>( object )
overloads for type needing special handling:
   write(the-special-type)

This is an elegant design:

   * Safe and portable.
   * Implementation is straight foward; no macros or other obvious hacks.
   * Users can call the layer that best meets their needs
   * Extensible at each level, yet need not be extended to
     be put to instant use.

Issues:

   * Writers need additional functions to deal with
     nested, delimited, and separated formats.  [XTL uses start and end
     functions for composites, vectors, and arrays.]
   * Overloading of the name "save" at three different levels
     is confusing. Rename them?

-- end --