Re: [boost] Proven ptr<>

From: Greg Colvin (Gregory.Colvin_at_[hidden])
Date: 2002-08-10 15:45:36

At 12:01 PM 08/10/2002, Peter Dimov wrote:
>From: "Peter Dimov" <pdimov_at_[hidden]>
>> From: "Philippe A. Bouchard" <philippeb_at_[hidden]>
>> > Hi,
>> >
>> >     Here is the proof ptr<> is faster and requires a lot less memory
>than
>> > shared_ptr<>.
>> >
>> >     The results speak from themselves:
>> > http://groups.yahoo.com/group/boost/files/ptr/
>> >
>> >     I know I don't take care of exceptions, but even with that the
>numbers
>> > start doubling or quadrupling...
>>
>> Philippe, try using #define BOOST_DISABLE_THREADS to get a fair
>comparison.
>> Looking at the times, I get the feeling that shared_ptr is using the
>thread
>> safe path. Apologies if this is not the case.
>
>Some more comments. Using <type_traits.h> prevents ptr.h from working on
>anything that doesn't use the SGI STL.
>
>The implementation is pretty clever. I _think_ that the whole shared_ptr
>spec can be implemented using your idea... if I were a standard library
>implementor writing a std::shared_ptr I'd definitely consider using the
>memory block header to store the data. :-)

The main question is whether the standard shared_ptr (or Boost's for
that matter), should insist that the shared object be allocated with a
special operator new.  If it is that opens up much more latitude for
clever implementations.  But it is also a virtue that shared_ptr doesn't
impose any such requirements.

As for the implementation, I think there are better approaches that
would cause no penalty for get().  The usual trick is to use size-
segregated storage pools set up so that one can get from an interior
pointer to an object header very quickly.  The Boost pool implementation
can probably be tweaked for this purpose.  Then a mumble_ptr<T> can just
store a proper T*, so get() has no overhead, and the arithmetic to
access the count is paid for only when needed.