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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-05-03 07:26:51

From: "Stewart, Robert" <stewart_at_[hidden]>
> From: Peter Dimov [mailto:pdimov_at_[hidden]]
> >
> > The problem is more psychological than technical. Given
> > std::shared_ptr<T>,
> > library designers will have a common ground and library
> > interoperability
> > will be almost a side effect. Given std::smart_ptr<T, SP, OP, KP,
> > WhateverP>, library designers - by default - will choose
> > different smart
> > pointer types for their interfaces, since it's well known
> > that personal
> > preferences vary wildly. Now, to achieve interoperability,
> > library authors
> > must agree on a common ground; or, to put in a different way,
> > they need to
> > establish a de-facto standard.
>
> Not at all.  Whether the standard, interoperable name is spelled
> "std::shared_ptr<T>" or "std::smart_ptr<T,SP,OP,KP>" is irrelevant.  If
> there is a sanctioned type for interoperability, library writers will use
> it.  Of course writing the former spelling is a bit easier than the
latter,
> but the latter can be made pretty by several means.
[...]
>
> There are probably other ways to make the spelling easier and prettier,
but
> it comes down to spelling, doesn't it?

You could restrict your view and label this a mere spelling problem, and you
could be right, for yourself. But it has nothing to do with spelling. It
comes down to officially sanctioning a single smart pointer type as the
"interop smart pointer."

It doesn't matter how this pointer is obtained. It could be a simple class
template (shared_ptr.) It could be a fixed point in a richer feature space
(smart_ptr<Var, Fixed, Fixed, Fixed, Fixed>.) The distinction is, indeed,
irrelevant (for the purposes of this discussion.)

> (All of this presupposes that reference counting is the desired common
smart
> pointer type for library interoperability.  I haven't seen any discussion
on
> whether that presupposition is correct.)

Suggest an alternative. Compare it with the current solution _with respect
to interoperability_.

> > The problem is not policy-specific. It's about degrees of freedom.
>
> Which can be restricted without abandoning policies.

Yes, of course. Provided that you do agree with the need to restrict the
degrees of freedom. Not everyone does. There is a conflict of interest here;
policy-based designs are all about freedom. A good policy-based design
doesn't have the design goal to produce an interop fixed point; even Andrei
agrees with this (compile-time vs runtime polymorphism; distinct types vs a
single type.)

The other option is to keep shared_ptr as the interop, "non-free" smart
pointer. As I said, it does not compete with smart_ptr. I don't see why
should smart_ptr be artifically evolved to swallow shared_ptr and auto_ptr;
I am not saying that it must not, I am saying that smart_ptr should have a
clear design focus that should not be compromised by religious,
nontechnical, attempts to "assimilate the competition." If the design calls
for shared_ptr emulation, so be it.