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
> or not but 'true' is authoritative in its quest to locate a current
>> 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.
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
> 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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk