Re: [boost] RTL: Relational Template Library

From: Rob Meijer (rmeijer_at_[hidden])
Date: 2005-10-05 15:33:49

On Wed, 5 Oct 2005, Jose wrote:

> On 10/5/05, Larry Evans <cppljevans_at_[hidden]> wrote:
> >
> >
> > Why can't the existing boost serialize library be used instead of a
> > separate persist library?
>
>
>
> I am not very familiar with the serialize library but I don't think they
> tackle
> persistence in the sense of providing persistant STL containers, i.e.
> containers
> that you can use in your app but that are stored in a file rather than the
> well
> known memory STL containers

The use of serializability as a prerequisite for storage in a persistent
container seems quite logical. Im currently looking if I can wrap a simple
string/file based persistent priority queue into a simple template library
that is somewhat compatible with std::priority_queue (libppq on
sourceforge). This should be quite do-able, but as Im not that experienced
with templates, it may take some more efford. I think that dependancy on
the serialisation library for classes that can be used to instanciate a
persistent container template from would be a sane way of working. That
way you just have to create a persistent container of strings using the
filesystem, and wrap this class in a template.

What I was currently thinking of was to require that each class that
could be put into the persistent priority queue template should have its
operator =(string) and operator string() overloaded by a serialisation
method, so the template could simply cast its internaly used strings to
and from the specified class, and each class should have its operator
int() overloaded so that its integer priority could be retreived from
the objects by using simple casts in the template.

One other thing to considder are the aplicability and efficiency of
algoritms paterns and adapters on persistent containers. I had to choose
a vector of persistent fifo design for my persistent priority queue as
a the heap aproach apeared to perform poorly in comparison.
I think there may be more paterns that may be efficient in memory, but may
be less optimal either in disk usage or in disk IO when mapped to files.
I dont believe there is a fifo in stl, only a deque, but the deque again
would be hard to code efficiently for both space and speed. Simple memory
based templates may be quite a bit harder to implement when using
serialisation+FS based storage. I think I could adjust the persistent fifo
to implement shrinking on both sides, making it usable for some more
algoritms that normaly work with a deque, but pushing data to both sides
as can be done with the deque would be very hard to do efficiently.

I think my libppq code might be of some use. I could probably use some
help with the templates. Random access containers would I think be
somewhat harder to implement efficiently.

Rob