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

Subject: Re: [boost] [Boost.Pool] TR1?
From: Nevin Liber (nevin_at_[hidden])
Date: 2011-04-12 10:57:59

On 12 April 2011 02:54, Phil Bouchard <philippe_at_[hidden]> wrote:

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

I know what it does.  Short of writing a full fledged garbage collector, I
don't know why that is a benefit.  (And I have my doubts that this is all
you need to standardize in order to write a standard conforming garbage
collector.)

Could you post a small code sample that shows how you would take advantage
of this?

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

Most of *what* makes use of a stack / heap differentiation function?  And
those aren't even the only two; shared memory, memory mapped files, etc.,
are others.  Heck, even knowing that something is in a pool doesn't tell you
if it is on the stack or the heap, because that really depends on where the
pool is allocated.

>  A ::pool.is_from() call could be a solution.
>
> I fail to see any hope in standardizing memory management without this.
>

Given that memory management has been working on various systems for
decades, I don't understand this statement.

-- 
 Nevin ":-)" Liber  <mailto:nevin_at_[hidden]>  [phone]