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