[EMAIL PROTECTED] (David Bradley) writes:
> David Abrahams wrote:
>
>>It's truly amazing how many problems are solved by the existing
>>boost::shared_ptr<> design, and it's a big advantage to have a
>>single-source smart pointer which "just works" in so many ways.
>>There's so much to learn about what it's capable of that many people
>>legitimately believe more parameterization would harm
>>understandability.
>>
>>
> A number of years ago we used a policy based smart
> pointer class. Worked really well. Allowed us to easily
> choose between intrusive and passive ref counts, as
> well as incorporate thread safe vs non-thread safe
> versions and easily use the type of smart pointer we
> needed for the task at hand all with the same interface
> and familiarity. Not to mention that once we got the
> basic implementation right, adding new policies was a
> breeze.
I don't doubt it a bit. A parameterizable smart pointer
is surely useful.
> We received some resistance from some developers
> claiming it was too complex. But in my view, if you
> don't want to look inside, the typedefs are simple
> enough, just use them.
We don't have typedef templates; you must mean
something else -- but I agree that it's easy to hide
parameterization in a smart pointer interface. All the
same, I think your experience with "some developers"
proves that this hiding isn't 100% effective. For
whatever reason, it incurred mental overhead for these
people.
> It's just like the rest of the STL that is quite
> complex, but people use it.
I really don't think so. The STL is designed around
parameterization. None of the components have a
similar flavor to boost::shared_ptr, which provides a
remarkably rich set of capabilities with practically no
parameterization.
> If one fear this, then why would they not fear
> std::string and std::wstring. Both those represent
> more complex templates. They each could have been
> implemented as a class, "simplifying" the
> implementation. Granted it's not a great analogy, but
> I don't think a policy based smart pointer is that
> much different.
It's not a great analogy because though the std strings
provide a complicated interface (even ignoring the
parameters), they're conceptually trivial. The boost
shared_ptr provides a simple interface and is
conceptually rich. The fear with smart pointers is
that a plethora of parameters will interfere with
understanding the concepts of shared_ptr which I guess
is supposed to represent the "perfect balance" for
common cases.
Please don't take this to mean I'm against a
policy-based smart pointer; quite the opposite. I've
said all along it would be great to have one in boost.
I've even wished I had an appropriate occasionally.
I just don't want to trivialize what I perceive to be
valid concerns, either. Understanding the costs of
complexity should be as important to the designer of
policy-based classes as to everyone else, if not more
so.
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
