By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,688 Members | 1,888 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,688 IT Pros & Developers. It's quick & easy.

Persistent STL?

P: n/a
Will you help an outsider trying to trace the current state of
persistent object technology?

"I expect that there will be persistent object stores with
STL-conforming interfaces fitting into the STL framework within the
next year."
--Alexander Stepanov, 1995

Has this happened? (In 1996 or another year.)

Thanks a lot,
--MAA
Jul 22 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
M?rio Amado Alves wrote:
Will you help an outsider trying to trace the current state of
persistent object technology?
I don't know the state of this but Objectivity offered at some
point STL-like containers which could be made persistent.

Unfortunately, it is impossible to create proxy containers
conforming to the container or sequence requirements (essentially,
because operator*() is required to return a reference). This would
allow some lightweight persistance mechanisms, e.g. persistent
containers. Of course, my property map approach would solve this
problem, too (well, actually, you wouldn't necessarily need property
maps per se but the separation of reads and writes).
"I expect that there will be persistent object stores with
STL-conforming interfaces fitting into the STL framework within the
next year."
--Alexander Stepanov, 1995


I think he was wrong. Some of the decisions in STL make it hard if not
impossible to create persistent object stores with STL conformant
interfaces.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting
Jul 22 '05 #2

P: n/a

"M?rio Amado Alves" <am*********@netcabo.pt> wrote in message
news:17**************************@posting.google.c om...
Will you help an outsider trying to trace the current state of
persistent object technology?

"I expect that there will be persistent object stores with
STL-conforming interfaces fitting into the STL framework within the
next year."
--Alexander Stepanov, 1995

Has this happened? (In 1996 or another year.)


In addition to Dietmar's response, and depending on your definition of
"persistent" there is a "serialization" library near completion at
www.boost.org. This is an excellent library by Robert Ramey which in
pre-release form can be downloaded from www.rrsd.com. It offers
out-of-the-box support for most(if not all) STL containers, along with
boost::shared_ptr.

Jeff F.
Jul 22 '05 #3

P: n/a
In message <ca**********@bluegill.adi.com>, Jeff Flinn
<NO****@nowhere.com> writes

"M?rio Amado Alves" <am*********@netcabo.pt> wrote in message
news:17**************************@posting.google. com...
Will you help an outsider trying to trace the current state of
persistent object technology?

"I expect that there will be persistent object stores with
STL-conforming interfaces fitting into the STL framework within the
next year."
--Alexander Stepanov, 1995

Has this happened? (In 1996 or another year.)


In addition to Dietmar's response, and depending on your definition of
"persistent" there is a "serialization" library near completion at
www.boost.org. This is an excellent library by Robert Ramey which in
pre-release form can be downloaded from www.rrsd.com. It offers
out-of-the-box support for most(if not all) STL containers, along with
boost::shared_ptr.


My feeling is that "persistent" ought to mean not just "serializable"
but also "transparent". That would require, among other things, that:

- use of a reference/pointer automatically loads the referenced
persistent object;
- some kind of GC process removes unused objects from memory, saving as
necessary;
- the library manages how objects are located within the file.

All of this is perhaps nearer to the idea of an object database than
simple persistent objects. I did a little searching on that subject a
few years ago, but didn't pursue it far. There were a variety of
solutions being offered, both commercial and free, but I don't think
there's anything which offers complete STL compatibility.

In the commercial sphere the big names seem to be Objectivity,
Versant/Poet, ObjectStore... and no doubt many others by now; at the
free end there's TEXAS from the University of Texas
(ftp://ftp.cs.utexas.edu/pub/garbage/texas/, last changed 1996) and
POST++ (http://www.garret.ru/~knizhnik/post/readme.htm)

--
Richard Herring
Jul 22 '05 #4

P: n/a
Excelent information! Extremely helpful! Thanks all very much!

I feel I owe some explanation of what I need this for. I'm preparing a
presentation on persistent containers, with references to the STL, for
RST 2004 (http://dmi.uib.es/~AE2004) I just wanted to make sure I
would not be boobooing too much when I say Stepanov's prediction in
1995 for 1996 is still uncomplished in 2004. I'm also developing a
persistent graph container called Mneson
(http://www.liacc.up.pt/~maa/mnesosn). It's in Ada but there are plans
to provide interfaces for C++ (as well as to C and Java). All this is
connected to the fact that the upcoming Ada.Containers library for Ada
2005 is partially modelled on the STL. I'll be thrilled to discuss
more if you want but please note I'm not a regular of this group so
please do it privately or in comp.lang.ada. Thanks.
Jul 22 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.