[Fwd: allocators not conformant to standard]

[Craig Perras]

Benjamin Kosnik wrote:
> 
> Hmm. I'm interested to see what ideas for implementing persistence have
> come up, if anybody's willing to share. I've gotten a lot of questions
> about this, and it seems as if using the hint argument
> for allocator::allocate(n, hint) as an aid to determine locality (20.4.1.1)
> is a pretty good way to do it.
>
> As Matt's pointed out, using a container address as a hint wouldn't work.
> It seems as if you could make the container's elements persistent though, as
> they could be passed in. . .  ie you could allocate elements and then
> pass in the returned pointer to allocated space as a hint argument to
> signify the intent to also allocate persistantly.

It seems to be difficult to get this to work correctly (and
transparently). I'm trying to implement object-level persistence (not
class level), so simply using a persistent allocator is problematic
without using some other mechanism (at run time) to differentiate
between persistent and transient objects. My strategy revolved around
passing in the address of the container/class as the hint to the
allocator (or new) so it can tell whether it is persistent or transient
(any address in the range of a persistent object store is persistent). 

Unfortunately, I didn't know about the above condition with the hint
parameter... I don't see how things would work correctly if someone
allocated a persistent vector, as there would be no way (?) to tell how
it was allocated. It would work fine if only the container's elements
were persistent, but what if you wanted the container itself persistent?
This may call for a change of strategy on my part, but so far I haven't
come up with one that maintains transparency. I think I may just have to
bend the rules here and pass in 'this' to the allocator.

If anyone wants more info on my persistent object store, feel free to
ask. Once I get further along, I plan to release it freely with source
code. 

> > See allocator<>::allocate(),
> > in line 602 of stl_alloc.h.  As you'll see, we have a hint parameter and
> > we don't do anything with it.

sorry - i was looking at simple_alloc and it's ilk.

--craig