Re: [boost] [Boost.Pool] TR1?

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.

Thanks,
-Phil