Re: [boost] persistence : current state, and plans for future ?

[Asger Alstrup Nielsen <alstrup@sophusmedical.dk>]

> Since I am about to use persistence, I will be playing with it a bit.
> Does the author Jens Maurer plan to release it for review ?
> Are there some points that are missing, or absolutely need fixing
> before review ?

In this context, it is worth mentioning that Jose Orlando Pereira has completely
rewritten his XTL library. You might remember that XTL was the second contender
that was discussed back when the topic of persistence was on the list.
Jose based his rewrite of XTL on the comments from that discussion. At the end,
you'll find the readme. He has not released the code publicly yet, but if you
ask for it, I'm sure you can get it.

Greets,

Asger Alstrup Nielsen
P.S. I'm cc'ing the XTL mailing list.

--

XTL2 is a complete rewrite of XTL with much improved application
program and internal interfaces: some conversion of application code
is required.

Before I describe the new features, please understand that this
release is only an early snapshot of work in progress and thus:

 - it "might" :-) have *BUGS*, so use XTL 1.4 if you want to be
   certain that your application compiles and runs;
 - support for stuff like object() and choice() in <xtl/macros.h>
   has not been ported yet;
 - only XDR format has already been ported (missing GIOP);
 - only the basic memory buffer and iostreams support has been
   ported (missing auto_mem_buffer);
 - allmost all portability hacks have been dropped, so older
   compilers will probably have trouble compiling it.

Now that I have convinced you to go back to XTL 1.4 and never look
back to this useless piece of code, let me explain why XTL2 was born.

1. Top layer: visitors
----------------------

The major improvement is the new generic visitor framework that
replaces obj_input/obj_input classes. This change is accountable for
the changes in the API. So, where we previously wrote:

   class X {
    ...

   	template <class Stream>
	void composite(Stream& stream) {
		stream.simple(x).reference(p).simple(y).array(a, s);
	}
   };

we now need to write:

   class X {
    ...

   	template <class Visitor, class Kind>
	void composite(Visitor& visitor, Kind) {
		visitor>>x>>reference(p)>>y>>array(a, s);
	}
   };

Although this looks mostly a "syntactic sugar" issue, this has
profound implications in how the visitor code itself can be extended. In fact
this will solves the problem found with auto_obj_* (described in item 4
of http://xtl.sourceforge.net/list/msg00063.html). 

It also allows for composition of annotations. For instance, in this
release it is possible to do:

   class Y {
    ...

   	template <class Visitor, class Kind>
	void composite(Visitor& visitor, Kind) {
		visitor>>aliased(reference(p), visitor.bucket);
	}
   };

which detects and restores pointer aliasing. And this works with other
pointer annotations, not just reference().

By now you should also have noticed the extra template parameter
Kind. This allows specilization of descriptions depending on the kind
of visitor. Currently, most annotations distinguish two kinds:
destructor and constructor, which correspond to obj_output and
obj_input streams in previous versions. For instance:

   class Z {
    int x, y, z;  // z should == x+y

   	template <class Visitor, class Kind>
	void composite(Visitor& visitor, Kind) {
		visitor>>x>>y;
	}

   	template <class Visitor>
	void composite(Visitor& visitor, constructor*) {
		visitor>>x>>y;
		z=x+y;
	}
   };

This also allows for visitors to be written at different abstraction
levels. Currently, visitors are simpler than formats in XTL1, as no
information on structure (such as start_composite/end_composite) is
passed to them. This is enough for XDR and GIOP, but not for a text
format.

<SCIENCE-FICTION>
In addition, we could consider a higher abstraction level
which provides tags for data elements. For instance:

   class Z {
    int x, y, z;  // z should == x+y

   	template <class Visitor, class Kind>
	void composite(Visitor& visitor, Kind) {
		visitor>>tag(x,"X")>>tag(y,"Y");
	}

   };

This should allow XTL to be used for external formats which
explicitly encode type description (XML comes to mind...).
</SCIENCE-FICTION>

2. Middle layer: formats
------------------------

As I had to change the format layer to make it compatible with the
visitor layer, I also simplified it a lot, getting rid of most
preprocessor macros.

3. Lower layer: buffers 
-----------------------

The lower layer is gone: formats now use directly C++ streams.

However, as it currently stands, the XDR format can also use a
zero-copy to memory strategy that makes it behave a lot like XTL1.

Notes:
------

The naive benchmark produces the exact same results for XTL2 and XTL1,
which, knowing how different they are, is quite amazing.

G++ seems to take even longer to optimize some tests. I have not
looked into it, but as XTL2 style is closer to STL (in particular,
with the algorithms) I expect it to eventually be compiler friendly.

I did my best to keep copyright notices in code derived from XTL1. If
I messed it up, please complain and I'll fix it.

For more information and to download a distribution, visit
http://xtl.sourceforge.net/ Files under ./include/ are distributed
acording to the GNU LGPL. See COPYING.LIB for licensing details.
Everything else is public domain.