[boost] Re: shifted_ptr: why?

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-02 08:50:24

"Andrei Alexandrescu" <andrewalex_at_[hidden]> writes:

> 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. 

Cool; I'd like to see it.

> 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.

Cool; I'd like to hear them.

> 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. 

I'm sure many of those issues can be dealt with, but that's less
likely if development continues in some non-Boost context.

> 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))

Dave, real gentle now, put the gun down.  I'm sure Andrei still has a
few more good ideas left in that head; we might need it some day.

> 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.)

Oh, please! Those predictions have been burned indelibly into our
collective memory.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com