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

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-04-18 22:56:28

"Dietmar Kuehl" <dietmar_kuehl_at_[hidden]> wrote in message
news:20020418225307.61166.qmail_at_web12307.mail.yahoo.com...
>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.<

You don't want to assign a smart pointer using one ownership policy to
a smart pointer using a different, incompatible ownership policy.

Consider you have an intrusive smart pointer with a count of five.
Then you assign it to a non-intrusive smart pointer, and further
duplicate that one. Then you have two cliques: one that uses the
internal counter, and the other that uses the external counter. The
assignment is unsound.

Policy-based design allows you to allow exactly the converting
assignments/construction that you want, and disable all others.

>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.<

I cannot understand what you say here, so I cannot comment.

>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.<

That is correct.

>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.<

The problem here is that you don't want to specialize smart_ptr<T> for
all types that, for example, use COM's intrusive reference counting.
There are many such types in the application and you don't really want
to configure smart_ptr separately for each.

The threading policy is not application-wide; there are places when
you want, and places when you don't want, to share smart pointers
between threads.

>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.<

How do you configure those?

>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).<

I'm not sure I exactly understood what "this" was. What was the point?

Andrei