RE: [boost] Re: Policy-based smart pointers revisisted

From: Sam Partington (Sam.Partington_at_[hidden])
Date: 2003-01-20 09:04:34

> [mailto:boost-bounces_at_[hidden]]On Behalf Of Paul Mensonides
> I don't buy this argument about the "complexity of many pointer
> types."  I'm
> not going to make a judgement on whether a few distinct smart pointers are
> better than a single super pointer.  I think we should have both and let
> users use whichever the like better.

I think the problem with offering too many solutions to the same problem is
that many users simply get baffled by the choice and use none.  Take some of
the people I work with, it has taken me many months just to get them to the
point where they use shared_ptr.  Just occasionally I see one of them write
boost::noncopyable, or even boost/operator.hpp.  If they had to decide
whether to use shared_ptr, or slightly_faster_ptr, I think they would simply
not bother.  Simply, they won't make use of something unless they see quick
and obvious benefits from it.  And I don't think this attitude is at all
unusual amongst programmers.

Also, I can't see any future standard having more than one new pointer, and
I can't see anything but the already widely used shared_ptr being it.

> However, all smart pointers provide
> basically the same interface, so keeping track of that is not that big an
> issue, as the differences in interface exist because of the
> various purposes
> of different smart pointers.  Also, because smart pointers are templates,
> you already have a different smart pointer every time that you instantiate
> it with a different type.  The compatibility issues between smart_ptr_A<T>
> and smart_ptr_B<T> can be handled without significantly more
> difficulty than
> smart_ptr<base> and smart_ptr<derived>.

There seems to me to be a very significant difference between
smart_ptr<base> -> smart_ptr<derived>, smart_ptr_A<T> -> smart_ptr_B<T>.
The first is simply a cast and an attachment to the reference count.  But
the second requires that every strategy policy understands how to make use
of every other strategy policy. i.e. for the following to work:

smart_ptr<T, my_own_cloning_policy> f();
...
smart_ptr<T, my_own_counting_policy> a = f();

my_own_counting_policy needs to understand what my_own_cloning_policy does,
and how to safely attach to it.  The problem becomes exponential with each
policy added.  Not to mention heavily dependent.  The other option, of
simply not making such conversions possible makes for incompaible libraries,
and lots of fix-up code to get around such problems.

My vote is to keep things simple, and to keep shared_ptr and scoped_ptr as
the only smart pointers.

That said, I do like the way shared_ptr can improve itself if you give it
something derived from counted_base, perhaps to compromise this method of
adding variety of implementation could be extended.  e.g. perhaps something
derived from clonable_base could have cloning characteristics?

As we've mentioned loki, is there any update on Loki -> boost integration?
A quick check of the archives and nothing seems to have been mentioned since
may or so.

Sam