Re: [boost] Re: Re: Preliminary submission: command line & config fil e library

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-17 17:57:10

dbradley_at_[hidden] (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
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution