[boost] Re: Traits-based design and ODR

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-05-02 14:54:27

"Greg Colvin" <greg_at_[hidden]> wrote in message
news:5.1.0.14.0.20020502104307.02ad0560_at_GMMAIL...
> >1. Shared pointers allow you to change at runtime the function with
> >which the pointer is destroyed.
>
> For shared_ptr, at construction time.

This is an irrelevant distinction:

shared_ptr<FILE> sp1(someHandle, fclose);
...
sp1 = shared_ptr<FILE>(sp1.get(), my_fclose);

(I'm not sure how shared_ptr<FILE>s are copied. I assume in this case they
call a system function to duplicate the handle.)

> In my experience, the fastest way to handle COM locally is to do AddRef
> once when constructing a shared_ptr, and Release once when counter
> goes to zero, and save the virtual function calls.

You don't save nothing in the case of shared_ptr because you release through
indirect function calls, which cost exactly as much as virtual calls (in COM
at least).

In my experience, the best way to deal with COM pointers is to use their own
mechanism - call AddRef and Release and not use two redundant,
unsynchronized, dangerous means of reference counting.

> I think copying is much more frequent than destruction.

destruction because you need to decrement the reference count of the old
object and check if it went to zero.

> >4. shared_ptr is a point in smart_ptr's design space.
>
> It could be, yes.  And vice versa.

I have a hard time understanding how the subset can be a superset of the set
to which it belongs.

For starters, how can I build a shared_ptr that's four bytes large?

> The beauty of Loki is that it IS a framework, and offers much
> power and convenience to those find it an appropriate framework.
>
> But the Standard Library, traditionally, is not so much a
> framework as a collection of utilities.
[snip]

Just for the record, I completely disagree with the argument and comparison
above.

> Another bastion is years of experience with shared_ptr, which
> indicates that it is "good enough" for most purposes, that it
> can be tweaked over time to handle other important purposes,
> and can provide hooks for user extension in unanticipated
> ways.

What can then be said about my and my colleagues' experience with several
refinements of Loki's smart pointer?

> The syntax is easy for the most common case, easy
> enough for anticipated extensions, and well within the skill
> of those who would design new extentions.

As I said: syntax /is/ the last bastion :o).

Andrei