Date: 2002-07-30 09:17:10
> Ok. I've rewritten my previous proposal to draw aside unusual operator
> (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
> + 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.
> just takes a little bit more memory.
> - Takes for granted that operator new (size_t) is not overloaded in
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk