[boost] Re: shifted_ptr: why?

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2003-10-02 02:49:21

"David B. Held" <dheld_at_[hidden]> wrote in message
news:blgicd$6b0$1_at_sea.gmane.org...
> "David Abrahams" <dave_at_[hidden]> wrote in message
> news:uekxw67bc.fsf_at_boost-consulting.com...
> > [...]
> > "The framework" is mere vapor as of today.  There's been some
> > work on it, but it would be crazy to hold up your own work waiting
> > for it.
>
> I wouldn't call it "mere vapor".  Rather, I'd call it "a challenge to
port".
> So far, gcc 3.3 is the only compiler that passes all the tests.  If I
could
> get it compile on at least two other compilers, I would submit it for
> review.  But it doesn't seem that a library that only works on one
> compiler meets the usual goals of Boost.  Feel free to correct me if
> I'm wrong.  Of course, I don't have that many compilers to try, either.
> Maybe if I had access to some better compilers, I would get farther.

I think we can add VC 7.1 to the list, although indeed the way it handles
constructors is crazy. It can be worked out though.

What Dave Held hasn't mentioned out of modesty is that he is working on a
policy-based smart_ptr implementation that targets a standardisation
proposal. He solved the exception safety problems in a manner that I
consider elegant. We'd like to thank this way to the boost community for all
the discussions that helped making smart_ptr better. Also, in the process,
we've made a number of observations about exception safety within the
context of policy-based design that we think might be of interest.

We hope to write policies that match the semantics of shared_ptr as closely
as possible. (Maybe not the syntax though; I convinced Dave that friend
functions are much better than member functions for this case at least.)

So, the state of affairs is, we do have a quality smart_ptr implementation
and test suite. As Dave said, the code, albeit standard, does not work on
most of today's compilers, which makes it less interesting to boost. And,
last but not least, the implementation makes use of the MPL, and I'm glad to
say, to good effect (yes, to make me agree on that, Dave has put a gun to my
head, yes, it was an automatic gun, yes, it was loaded, and yes, he cocked
the gun!!! :o))

The description of what Dave did and does to smart_ptr will be documented in
an ongoing series of Generic<Programming> articles, starting with
http://www.moderncppdesign.com/publications/cuj-10-2003.html. The next
issues in the series, unfortunately, will only appear in dead tree edition
and as such won't be presto available online.

As per shifted_ptr, my take is that it is an original design responding to a
need. That originality would not be taken away should shifted_ptr be fit
into smart_ptr; au contraire, smart_ptr would just save some clutter off the
implementation. As of now, shifted_ptr certainly can be analyzed and
evaluated on its own. shifted_ptr's possible future admission would only
increase the number of smart pointers in boost (which I had predicted, but
now of course everybody forgot, boo-hoo-hoo etc.), thus also raising
interest in a policy-based design to factor together commonalities and to
give a coherent chassis for varied original designs.

Andrei