Boost logo

Boost :

Subject: Re: [boost] [Boost.Pool] TR1?
From: Phil Bouchard (philippe_at_[hidden])
Date: 2011-04-12 03:54:26

On 4/11/2011 11:19 PM, Nevin Liber wrote:
> On 11 April 2011 22:40, Phil Bouchard<philippe_at_[hidden]> wrote:
>> On 4/11/2011 6:02 PM, Dave Abrahams wrote:
>>> Whatever the costs, you have a point because this is something that
>>> can only be implemented portably by the standard. I'm certain that
>>> Boost.Pool invokes undefined behavior whenever it returns false from
>>> is_from().
>> Indeed 'false' basically means your not sure if the pointer will eventually
>> be part of the pool
> But it may be undefined behavior to pass that pointer to is_from.

That's right but I am not sure about the complexity in making its
behavior non-undefined even if the complexity is not constant. Because
otherwise is_from() would be quite useless if a non-true value crashes
the application.

>> or not but 'true' is authoritative in its quest to locate a current object.
> But it doesn't tell whether the object was directly allocated in that pool
> or if it was indirectly allocated by being an aggregate in another data
> structure.

Well it tells you whether an object or one of its aggregate is within
any of the memory pages reserved by the pool.

> What exactly is the benefit of this?

To make it generic in order to standardize memory management eventually
because most of them make use of a stack / heap differentiation
function. A ::pool.is_from() call could be a solution.

I fail to see any hope in standardizing memory management without this.


Boost list run by bdawes at, gregod at, cpdaniel at, john at