[boost] Re: shifted_ptr<> w/ lock mechanism

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2003-01-29 21:01:45

"David Abrahams" <dave_at_[hidden]> wrote in message
news:u65s7k8pq.fsf_at_boost-consulting.com...
> "Philippe A. Bouchard" <philippeb_at_[hidden]> writes:
> > I believe there is not that much left to do besides optimizations.
>
> Have you tried a comparison against a shared_ptr using an optimized
> count allocator?  Nobody has invested as much effort in optimizing
> shared_ptr as you are pouring into shifted_ptr, but an experiment I
> did years ago made a huge difference in the efficiency of shared_ptr
> just by implementing a crude allocator for count objects (took me
> about 10 minutes to code up).  For me to find shifted_ptr convincing
> I'd have to see a noticeable performance improvement over using an
> optimized count allocator with shared_ptr.

My understanding is that shifted_ptr mandates allocating *your* objects
inside *its* "doped memory" area by using placement new. (Phillippe, please
correct me if I'm wrong.) This slashes many good uses of smart pointers,
which include, but are not limited to (damn, I feel I talk like a lawyer
:o)): object factories (unless they use shfted_ptr from the get-go), the
Template Method pattern (ditto), cross-DLL communication, object brokers
(COM/CORBA), working nicely with other allocators. All these idioms require
you to grab a pointer to an object that was constructed elsewhere. If my
understanding is correct, shifted_ptr is not able to do that, while
shared_ptr is.

These are use cases that I personally find important, so, although there
existed some precedent back in 1999, I did not consider using a custom
allocator (that would allocate the object plus extra memory for
bookkeeping) in mc++d. At any rate, anyone comparing shifted_ptr with
shared_ptr should keep in mind that one has an apple flavor and the other
an orange flavor.

It would be interesting to see how much the implementation of shifted_ptr
is simplified if it's put into an Ownership policy of the Borg, er,
loki::smart_ptr. I guess a lot. That would nicely let the users decide
whether they can do with allocating objects with placement new and enjoy
the additional performance. Of course, all that *after* fixing smart_ptr's
buggy constructor :o).

Andrei