🚀 go-pugleaf

In article <xg3ohtwl6t0.fsf@marsh.cacs.usl.edu>,
Anil Vijendran <akv@cacs.usl.edu> wrote:
>>>>>> On 18 Nov 1995 22:24:33 GMT, wilson@cs.utexas.edu (Paul Wilson)
>said:
>
>I have a question in relation to this... I've seen persistence
>systems/libraries where the allocator or the heap itself is passed
>using the placement syntax... for example,
>
>	ptr = new (pstore) shape;
>
>I have always been wondering how the constructor of the class could
>allocate its data members on the same heap the top level object was
>placed in.
>
>I think the placement syntax when extended to persistent stores and
>such, whatever goes as the placement-expression, should be passed to
>the constructor too.. Or can this be done sans such an extension? 

It can be done without an extension, if there's a routine that an
object can use to find out what heap it itself is allocated in.

The Texas persistent store provides such a routine.  Every in-use
page of memory is part of a persistent store or a transient
(conventional non-persistent) store, and this routine simply checks
to see what store the page belongs to.  So an object can effectively
ask "where am I?" and then "allocate this there too".

This is not necessarily the best way to do it, however, because checking
what store owns a page takes dozens of instructions.  Another way of
doing it is for the object to hold onto a pointer to its store, and
use that when allocating its sub-objects.  That way the lookup only
happens once.

Yet another way to do it is to capture the pointer to the store object
(essentially an allocator) from the constructor and hold onto it for
later use, so that the lookup doesn't have to be done at all.

We're trying to figure out the most graceful way of making this work
with STL.  We haven't yet grokked all of the standardsese in the new
working paper, but it doesn't seem hard.  (If it is hard, STL needs
to be fixed.  My earlier mail on this topic was based on ignorance
of the new working paper---I didn't realize that the allocator model
had changed from the Stepanov version.)

Does anybody know of a clear description of the current allocator model?
Do the new books on STL---e.g., Nelson's---explain this, or are they out
of date because things have changed very recently?

Is there a standard set of programming style recommendations for
using allocators?

  Paul

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