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

From: scleary_at_[hidden]
Date: 2002-07-30 09:17:10

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

> Pros & cons:
> 
> + Fast smart pointer.  Cannot be faster:
>     + sizeof(ptr<int>) == sizeof(int *) (for copying);
>     + one operator new (size_t) call to allocate the object (no counters).
> + Memory benefits:
>     + sizeof(ptr<int>) == sizeof(int *);
>     + sizeof(* ptr<int>) == sizeof(int) + 1;
>     + thus maximises the number of pointers growth referring to one
object.
> + Simple syntax:
>     + no need for policy-based functions;
>     + no need to inherit from counted_base;
>     + no need for operator new (size_t, ...) like in my previous examples.
> + Doesn't matter if you don't use ptr<> to assign the allocated buffer.
It
> just takes a little bit more memory.
> 
> - Takes for granted that operator new (size_t) is not overloaded in
specific
> classes and if so, is not using direct malloc() calls.  But it would be
> possible to assert at compile-time it is not overloaded.
> - It would begin to be more complex for low-level dynamic memory routines.
> - This is why I am recommending boost::pool as the holding namespace.

- Introduces memory overhead for *every* dynamically-allocated object not
placed in a ptr<>.
- Cannot be used in any project where the end user wishes to displace the
global operator new & delete.

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

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.

        -Steve