[boost] Re: Proposal: boost::pool fast pointer

From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2002-07-30 11:28:04

(Something is blocking my messages sometimes).

> > Ok.  I've rewritten my previous proposal to draw aside unusual operator
> new
> > (size_t, ...) syntaxes by overloading the global operator new (size_t).
>
> Just for clarification: you're not actually overloading it; you're
> displacing it.  You were overloading it in your previous proposals.

It's true.  My mistake.

[...]

> - Introduces memory overhead for *every* dynamically-allocated object not
> placed in a ptr<>.

Yeah but is it really that bad when you know that shared_ptr<> is already
taking two integers in length?  And also by considering the highly probable
fact that more than one pointer will point to the same object:
sizeof(shared_ptr<int>) x 2 + sizeof(malloc(int)) *>* sizeof(ptr<int>) x 2 +
sizeof(malloc(int + 1))

> - Cannot be used in any project where the end user wishes to displace the
> global operator new & delete.

This would depend on the project you are working on.  But applying this to
TrollTech's QT projects would be really beneficial since every widget is
taking a lot of memory anyways.

> Also, the name "boost::pool" is already taken.

Sorry.  What I was trying to mean was: 'pool' related.

> If you're really dead-serious about removing the allocation of the shared
> count in shared_ptr<>, you might want to consider a pool-based approach.
> That will get you an amortized single-allocation-per-object.
>
> Back when shared_ptr<> was being designed, Dave Abrahams (I think it was
> him, anyway) did some speed testing with a shared_ptr<> that took its
> counter from a handmade pool -- and IIRC, it showed some favorable
results.
> Since then, no-one has ever seriously explored making a shared_ptr<> that
> used a pool allocator; you might wish to try that approach.

I'm not familiar with this allocator but in your opinion would it be as
simple to use in the end?

Philippe A. Bouchard