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
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
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk