🚀 go-pugleaf

My current understanding of STL allocators suggests that the standard
is badly designed.  I'd be happy to be corrected if I'm wrong.

As I understand it, STL templates can take an allocator argument,
so that you can instantiate the templates to give different types
that use different allocators.

This seems to me the wrong way to go.  The allocator should be specified
for particular instances to make the system really useful.  That is,
you should be able to allocate instances of exactly the same class
in different ways.

For example, if one of your allocators manages shared memory and another
manages private memory, you'd like to have data structures that can cross
that boundary.   Suppose you want to create a private list that is
a prefix of a shared list, or some kind of private tree whose subtrees
are shared.  You'd like the instances to be of the same type, so that
you can have pointers from one to the other without krufty special-case
code.

An example that's closer to my heart is that I want to support STL
classes with orthogonal persistence.  I'd like it to be possible
for a piece of code to operate on instances of a class irrespective
of whether they're allocated in transient memory, or in a persistent
store.

(E.g., for a database transaction, I may have temporary relations
implemented as collections on the transient heap, but permanent relations
allocated on the persistent heap.  I'd like the same code to be able to
operate on either, because the query processing steps don't care about
whether they're operating on intermediate or permanent relations.  I'd
also like the transient relations to be able to hold pointers to objects
that may themselves be transient objects generated during query processing,
or persisent objects faulted into memory from the p-store by a search query.)

As I understand it, ObjectSpace STL does support per-instance specification
of allocators, although I'm unclear on the details and whether it actually
works the way I'd like.

Will the STL standard eventually support this?

Am I mistaken that the standard STL allocator model conflicts with what
I want to do?  Are instantiations of templates with different allocators
different types, requiring different code to operate on them?  I suppose
we could write all of our code as template functions and generate two
versions of everything, but that's ugly and not a complete solution.

(A little background here: by default, our persistent store does not
checkpoint pages of transient memory.  If a failure occurs during a
transaction, all transient objects simply disappear, and all changes
to persistent data are lost---i.e., not propagated to the persistent
store.  It is assumed that the transaction will be restarted and the
transient data will be regenerated.)

-- 
| Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (wilson@cs.utexas.edu)
| Papers on memory allocators, garbage collection, memory hierarchies,
| persistence and  Scheme interpreters and compilers available via ftp from 
| ftp.cs.utexas.edu, in pub/garbage (or http://www.cs.utexas.edu/users/wilson/)      


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]