On Wed, 5 Oct 2005, Jose wrote:
On 10/5/05, Larry Evans <cppljevans@cox-internet.com> 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