RE: Persistence Library Needed in Boost? (Was: [boost] A tip from the Dr.)

From: Jack M. Thompson (JMThompson_at_[hidden])
Date: 2002-01-30 17:21:59

Can you explain item h a little more?

And how should item e work.  Are you trying to say that all objects
using the persistent object need to be affected?  How can that happen?

-----Original Message-----
From: rameysb [mailto:ramey_at_[hidden]] 
Sent: Monday, January 28, 2002 2:52 PM
To: boost_at_[hidden]
Subject: Re: Persistence Library Needed in Boost? (Was: [boost] A tip
from the Dr.)

I have been a user of the MFC implementation of Object persistence
for some time and found it very useful.  However it is lacking in
some areas.  This has convinced me to create my own implementation
of C++ object persistence.

My requirements are:

a) code portability - depend only on ANSI C++ facilities.
b) code economy - exploit features of C++ such as RTTI, templates, 
and multiple inheritence, etc where appropriate to make code
shorter and simpler to use.
c) independent versioning for each class definition.
d) pointer persistence.
e) proper restoration of pointers to shared data.
f) persistence of STL containers
g) archive portability - should be portable from one platform to 
another.
h) orthogonal specification of streambuf input/output to permit 
seamless filtering (e.g. encryption, compression, etc).

In addition it would be convenient if there were a choice of 
archive formats, serialization or xml.  Though I think this would be 
difficult to achieve without without makeing the library hard to use.

Before getting started I searched around for current implementations. 
I found
several.

MFC
===
This is the one that I am very familiar with.  I have used for 
several years and have found it very useful.  However it fails 
requirements a), b), c), e), f) . In spite of all the requirements 
not fullfilled, this is the most useful one I've found.  It turns out 
that class versioning - partially implemented in MFC - really is 
indispensible for my applications. Inevitably, version 1.x of a 
shipping program needs to store more information in files
than was originally provided for.  MFC is the only implementation that
supports this - though only for the most derived class.  Still its 
better than nothing and does the job.  MFC doesn't implement 
serialization of STL collections.  Though it does so for MFC 
ollections.

CommonC++ libraries [1]
=======================
As far as I can tell, this closely follows the MFC implementation but
does address a few of the issues.  Is portable and creates portable 
archives but skips versioning.  It addresses compression though not 
in the way that I would prefer.  so it fails to address b), c), e), 
g) .

Eternity [2]
=======================
Fails c), e), f?), g)

Holubs implementation [3]
=========================
This is the article that first got me thinking about my own 
requirements for a persistence implementation.  Interesting and worth 
the read if you can overlook the annoying arrogant tone of the prose. 
This implementation fails b), c), d), e), f)

My own implemenation addresses all the above criteria

In reading messages in this forum I would like to make the following 
observation.

It seems that "persistence library" doesn't me the same thing to 
every one. I have been using the term serialization and persistence 
interchangably.  However, the concept described below in 
http://www.codefarms.com/ppf/ is quite different and made me realize 
that its possible that we're not all talking about the same thing.  
What I refer to is a general mechanism for saving the current stated 
of a collection of instances of C classes to permanent storage and 
restoring an equivalent memory image at a later time

I would guess that there are not widely agreed upon meanings for 
object persistence, serialization, etc.

Robert Ramey

References:

[1] CommonC++ libraries, David Sugar and Daniel Silverstone, 
http://www.gnu.org/software/commonc++

[2] Eternity, Nicola Santi, http://sourceforge.net/projects/eternity-
it/

[3] "Roll Your Own Persistence" Allen Holub Microsoft Systems Journal 
vol 11, no 6 Jun 1996

--- In boost_at_y..., "Gustavo Guerra" <gustavobt_at_m...> wrote:
> 
> ----- Original Message -----
> From: "jackthompson99" <JMThompson_at_E...>
> tip from the Dr.)
> > I'd like to find out if there are any other libraries available 
that
> > do the same thing BEFORE trying to submit this as a new boost
> > library.  Do you know of any?
> >
> 
> Some links:
> 
> Persistent Pointer Factory
> http://www.codefarms.com/ppf/
> 
> Simple XML Persistence
> http://sxp.sourceforge.net/
> 
> A class library for persistent object management in c++
> http://www.mb.hs-
wismar.de/Mitarbeiter/Pawletta/00Uwe/persistent/persistent.
> html
> 
> GNU Common C++
> "Common C++ is a C++ framework offering portable support for 
threading,
> sockets, file access, deamons, persistance, and system services"
> http://www.voxilla.org/projects/projape.html
> 
> Issues in the Design of a Reflective Library for Checkpointing C++ 
Objects
> http://www.cse.psu.edu/~kasbekar/papers/srds99.pdf
> http://www.cse.psu.edu/~kasbekar/papers/srds99.ps
> 
> e4Graph
> "a C++ library that provides your program with reliable, efficient 
and
> portable persistent storage for graph like data"
> http://e4graph.sourceforge.net/
> 
> Roguewave SourcePro Core
> http://www.roguewave.com/products/sourcepro/core/
> 
> Regards
> Gustavo Guerra

Info: http://www.boost.org  Send unsubscribe requests to:
<mailto:boost-unsubscribe_at_[hidden]> 

Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/