[boost] policy-based smart pointers are EVIL! (was: Intrusive smart pointer)

From: Dietmar Kuehl (dietmar_kuehl_at_[hidden])
Date: 2002-04-18 17:53:07

Hi,

now that you are looking into this message, I can admit that I'm not
entirely opposed to policy-based smart pointers but there are
considerable advantages of classes not using policies. The biggest
disadvantage of policy-based smart pointers (this actually applies to
all policy-based entities) is added flexibility. Of course, the biggest
advantage of policy-based smart pointers is added flexibility, too.

OK, before you start thinking I have gone entirely stupid (which you
are, of course, free to think anyway), I want to clarify a little bit:
The problem with policy-based designs is that similar entities with a
similar intention become incompatible. For example, you cannot assign a
smart pointer using an intrusive counter to a smart pointer using an
external counter (well, if you are really careful this may be even
workable but in general it is definitely not). That is, for the sake of
interfaces you want to use just one style for an entity.

Of course, this is just one side of the coin. The other side is that
you
definitely want to use different approaches to deal with special
situations. For example, you can't use an intrusive smart pointer to
maintain a Boolean object but you need an intrusive smart pointer if
you
want to return a pointer to 'this'. That is, neither approach is
workable
in both situations. Also, there are situations where you definitely
want
to avoid to mix different approaches like when having smart pointers
which are local to a thread while other smart pointer need
synchronization across different threads.

My general feeling is that there needs to be something like
'boost::smart_ptr<T>' which is appropriately configured for the
specific
needs of type 'T' (eg. intrusive vs. external counters are probably
type specific), to application wide preferences (eg. multi-threading
support is likely to be configured application wide - at least for most
cases), and otherwise useful defaults. This would be the type used for
passing around pointers to 'T' objects. For specific needs like
package-internal maintainance, processing local to functions, or
special
performance requirements differently configured smart pointers may be
used. Of course, 'boost::smart_ptr<T>' would probably be implemented
using a policy-based smart pointer underneath for which eg. template
typedefs would be pretty useful (if these allow [partial-]
specialization). In the absence of template typedefs some suitable
work-around is probably a viable choice to use instead.

I haven't been following the smart pointer discussions recently so
please excuse if this has been pointed out before (well, I guess it
probably was pointed out but I think it is worth keeping this mind).
--
<mailto:dietmar_kuehl_at_[hidden]> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>
=====
<mailto:dietmar_kuehl_at_[hidden]>
<http://www.dietmar-kuehl.de/>
__________________________________________________________________
Gesendet von Yahoo! Mail - http://mail.yahoo.de
Sie brauchen mehr Speicher für Ihre E-Mails? - http://premiummail.yahoo.de