Boost logo

Boost :

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

The way I look at persistence or serialization is about the same as what
you are saying. The mechanism must simple save and restore all of the
objects. All of every objects data must be restored as designated by
the developer (some parts of the object won't need to persist).

As far as using pointers and restoring them, I agree, in a way. I don't
use pointers much anymore, but when I do, I like to make sure that all
of the code that handles their lifetime is very well controlled.

-----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
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

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

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

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 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


[1] CommonC++ libraries, David Sugar and Daniel Silverstone,

[2] Eternity, Nicola Santi,

[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
> > do the same thing BEFORE trying to submit this as a new boost
> > library. Do you know of any?
> >
> Some links:
> Persistent Pointer Factory
> Simple XML Persistence
> A class library for persistent object management in c++
> http://www.mb.hs-
> html
> GNU Common C++
> "Common C++ is a C++ framework offering portable support for
> sockets, file access, deamons, persistance, and system services"
> Issues in the Design of a Reflective Library for Checkpointing C++
> e4Graph
> "a C++ library that provides your program with reliable, efficient
> portable persistent storage for graph like data"
> Roguewave SourcePro Core
> Regards
> Gustavo Guerra

Info: Send unsubscribe requests to:

Your use of Yahoo! Groups is subject to

Boost list run by bdawes at, gregod at, cpdaniel at, john at