Re: Reasons for not standardizing policy based smart pointers
[resend after 48 hrs]
Gennaro Prota wrote:
In a blog entry I read recently, Herb Sutter states:
One of the primary reasons (but not the only one) why policy-based
smart pointers didn't make it into C++09 was usability: Although
Loki::SmartPtr can express shared_ptr easily as just one of its
configurations, the user has to type lots of weird stuff for the
policy parameters that is hard to completely hide behind a simple
typedef, and so the user would be less inclined to use the
feature:
shared_ptr<int>::type p;
shared_ptr<int> p;
Too bad we didn't have template aliases then, because now we could
have our cake and eat it too:
// Legal in C++09
//
template<typename T>
using shared_ptr =
Loki::SmartPtr<
T,
RefCounted, NoChecking, false, PointsToOneObject,
SingleThreaded, SimplePointer<T>
>;
shared_ptr<int> p; // using the alias lets us
// have a completely natural syntax
I wonder: what were the other reasons Herb hints at? Though he says
that they are not "primary" I hope they are still very serious for
"falling back" to a supposedly inferior alternative in a standard
which will set the shape of what we'll use for the next 20 years.
There were mostly technical reasons. There have been concerns related to
library interoperability, as Beman noted; I believe those could have
been assuaged by appropriate use of template typedefs and default
parameters. After all, all of the dynamic configurability that was
needed for a shared_ptr clone could have been taken care of in one set
of default policies; maybe it wasn't clearly communicated that the
option to did things statically (through type parameterization)
complements, and does not preclude, doing them dynamically as well.
But the basic problem was "simple": the PBSP project had two ambitions:
to 100% emulate shared_ptr and auto_ptr, in addition of course to
enabling an array of other designs. I have considered anything less as a
failure: After all, I couldn't come with a straight face and say, "hey,
here's this ultimate design - the only smart pointer you'll ever need -
um, except for auto_ptr, which I can't emulate."
And that's quite what happened: emulating auto_ptr in addition to
everything else turned out to be so onerous as to become a Pyrrhic
victory. Dave B. Held and myself fought valiantly to come up with a
compelling design, but we couldn't: the result had nothing of the
elegant simplicity of policy-based design, but instead was a mishmash of
heavy-handed tricks and essentially a swath of duplicated code to
support auto_ptr. There were too many bears to make dance out there. I
don't think the committee would have been impressed; I know we weren't,
and how could we sell something we didn't believe in? Also, the
semantics of typedef templates were actively being debated on so we
couldn't count on the semantics we needed.
Meanwhile, both Dave and myself were under significant time pressure and
we were more or less forced by circumstance to work on other projects. I
still believe it's possible to devise a PBSP that achieves our goals
within a clear, concise design; we just couldn't find that in time.
Andrei
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]