Boost logo

Boost :

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

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]>  (847) 691-1404

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