"Andrei Alexandrescu" <[EMAIL PROTECTED]> writes:
>> I'd like to draw an analogy with shared_ptr. You can provide smart pointer
>> with 5 policy parameters, that user can redefine. Still, I would use
>> boost::shared_ptr, just because I don't want 10 incompatible smart
> pointers in
>> my program due to small advantage each one has in special situation.
>
> Ok, I can't hold it :o). It's funny how policy_based smart pointers have
> been vigurously disapproved by some boost participants for various reasons,
> yet anytime I log in here there's discussion about a yet another
> smart_pointer du jour, designed from scratch, and most of the time
> incompatible with all others.
I think that's a gross mischaracterization. The only new design I've
seen discussed in the past year is something (non-portable IIUC) that
most people can't get their heads around and don't seem to need. It's
an interesting design idea which blends the advantages of intrusive
and non-intrusive smart pointers, but I think is still largely
unproven.
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.
I don't think anyone disapproves of the idea of a customizable smart
pointer design. It would be great to have for special-purpose jobs.
If boost::shared_ptr could be implemented in terms of it, so much the
better. If you think it would address some real needs that aren't
covered by existing boost libraries, you should bring a design up for
formal review. If people think they need it, I'm sure it would be
accepted.
Personally, I'm not sure about the best way to get to a customizable
smart pointer. For example, it would be very interesting to see what
it looks like to apply the new iterator adaptors design in the boost
sandbox to smart pointers. If using one library for all smart
pointers is good, using one library for all dereferenceable types is
surely better (or maybe not, but I'd like to see how it pans out) ;-).
-Dave
--
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
