Boost logo

Boost :

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

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