Boost logo

Boost :

From: Brad Spencer (spencer_at_[hidden])
Date: 2002-10-21 14:26:15

On Fri, Oct 18, 2002 at 10:08:49AM -0400, scleary_at_[hidden] wrote:
> Yes, this is a bug for purge_memory() and release_memory(). I'll update it
> when I have time (probably not for a few weeks). It will essentially do the
> same thing as your work-around.

Ok. It is good to know that my workaround is correct. Thank you.

> > Also, perhaps next_size should grow by a factor of 1.5 instead 2, as
> > is suggested by Andrei Alexandrescu in "Modern C++ Design" (I don't have
> > the page handy :)
> When I wrote Boost.Pool, I considered two different growths for next_size:
> next_size = next_size * 2;
> and
> next_size = next_size * 2 + 1;
> There's a disadvantage to the "*2+1" scheme: the "array doubling" scheme has
> a historical precedent, which makes it more likely that general-purpose
> allocation schemes are tuned to supply allocations of powers-of-2. Before
> making this decision, I reviewed a few Standard library implementations (all
> the ones I had access to at the time), and found that std::vector used array
> doubling in every one.
> I have not heard of this growth by 1.5 idea, and I just took a brief look
> through Andrei's book and couldn't find it. Could you look up the
> reference, or maybe just describe the advantages of that approach?

That would be because I got my books mixed up :) I didn't have them
with me when I wrote the original message. I actually saw the 1.5
idea in Herb Sutter's More Effective C++ (Item 13). He references
Andrew Koenig's September 1998 column in the Journal of
Object-Oriented Programming.

The Sutter item is available online:

I could not find any online version of the JOOP article, although it
seems to be called "Why Are Vectors Efficient?". It is referenced on
Koenig's biography page:

Sorry about the wild goose chase.

Brad Spencer - spencer_at_[hidden] - "It's quite nice..."
Systems Architect | InfoInterActive Corp. | A Canadian AOL Company

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