Re: [boost] Smart pointer poll

From: Dietmar Kuehl (dietmar_kuehl_at_[hidden])
Date: 2002-05-04 18:52:40

David B. Held wrote:

> 1. Is a policy-based smart pointer still worth pursuing, or are there too
> many contentious issues that will never get resolved?

I think a policy-based smart pointer is a useful approach and probably
something which should go into the next standard if not already into the
library TR. Since there are a bunch of issues to be resolved, I would,
however, rather move a little bit slower than introducing a premature
version. That is, although it would be desirable to have an extended set
of smart pointer in the library TR, I would rather omit it than hurrying
too much. Note, that I'm not talking of a policy-based smart pointer in
isolation: It would be an error to introduce a different smart pointer
(or a set thereof) without being ready with the whole thing which, IMO,
includes a policy-based smart pointer (or is even made up solely of such
a thing; I think this is one of the bigger issues which still needs
resolution).

> 2. If a policy-based smart pointer *is* worth pursuing, is
> boost::loki::smart_ptr heading in the right direction?

I cannot comment on this question (or it's subquestions). My major
concern are interfaces and basically all I'm asking to be considered in
the design is a clear and simple approach how smart pointers are used in
interfaces to libraries/components/packages such that interoperability
between different packages is not dwarved.

> 3. Which is best for Boost, and which is best for a library proposal?
> A) just shared_ptr
> B) just smart_ptr
> C) shared_ptr + smart_ptr
> D) other

I haven't seen the discussion of the last few days yet but all I have
seen so far indicates that this is one of the questions which still
needs to be resolved! I doubt that A. is the way to go although it may
be the right choice for interfaces. B. is a more likely choice, IMO,
than A. although there are definitely things I would like to see
addressed first. I think that C. is an unlikely candidate although a
policy-based smart pointer (smart_ptr) and a distinguished name (if this
is what shared_ptr refers to) may be a viable approach. My guess is that
D. is the way to go: So far, I haven't seen a satisfactory solution to
the problems I'm seeing (basically a reasonably configurable smart
pointer used in interface; apparently my traits approach does not work
but I have not seen any alternative yet) and I think they are important
enought to warrant some more consideration.

Here is just a small discussion why I don't think that there is no
complete design, yet (if specific points were addressed recently, I may
have missed them):
- Only a policy-based smart pointer without a clear way to form types to
   be used in interfaces will yield incompatible interfaces, although the
   problem might be reduced to some degree by appropriate conversions. I
   think that a policy-based smart pointer should be included, however,
   for use in special situations even interfaces (if special needs arise,
   these should be taken care of), for use inside components, and as the
   basis to implement the interface pointers.
- Only shared_ptr (meaning a mostly runtime-configured approach to
   provide different maintainance policies) seems to heavy-weight and to
   a certain degree to inflexible for me. Of course, it can be made even
   heavier to accomodate the needed flexibility but I don't think this is
   a reasonable avenue. Before people claim that shared_ptr has all
   flexibility possible, let me point out that it has not: It does not
   have the flexibility to enforce choices at compile-time (eg. to
   require a thread-safe, intrusive count).
- A policy-based smart pointer with a set of default policies to be used
   by convention for interface purposes (that is, just like my first
   option with a simple convention) either not really solves the problem
   that different types may need different policies (eg. an external
   count for most types and an intrusive count for types possibly
   returning themselves) or has the same problem of being heavy-weighted
   like shared_ptr.

OK, after having given my answer, I will see what others write :-)
-- 
<mailto:dietmar_kuehl_at_[hidden]> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>