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