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

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-05-03 09:54:11

From: Peter Dimov [mailto:pdimov_at_[hidden]]
> 
> 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."

Your contention is that given a policy-based smart pointer, library
developers will configure it differently for each library, thus preventing
interoperability, unless I have completely missed the point.  My contention
is that there only needs to be agreement on which smart pointer is the
default for libraries.  How that smart pointer is spelled is largely
irrelevant, so long as there is one.

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

Now I'm confused, because it seems that here you're saying what I was: it
doesn't matter how you spell the pointer type, just that there is one.
Perhaps we're in violent agreement.

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

I haven't given this the thought it would require.  I was just raising a
concern that it seems an implicit decision was made that a reference counted
smart pointer, such as boost::shared_ptr, was the proper choice.

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

I agree that we need to restrict static degrees of freedom.  The notion that
there may be some things that can adapt at runtime, under the covers, is
interesting and may mitigate some of the concerns of those in the opposite
camp.

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

As I thought I had made clear, the policy-based smart pointer can be
appropriately constrained for interoperability purposes.  The default
policies, for example, could be selected for maximal interoperability and
would be easy for library designers to use by default.  The smart pointer
itself, because it is policy based, won't include interoperability as a
design goal, but that doesn't mean it can't be used for that purpose.

> The other option is to keep shared_ptr as the interop, 
> "non-free" smart

That is certainly a possibility, but as has been discussed in other threads,
the restrictions it places on the handling of the type may be more severe
than required for interoperability.

> 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 see value in creating a single, standardized smart pointer framework,
extensible via policies, traits, or whatever other magic someone devises,
that can do all of the reasonable things one needs done with a smart
pointer, provided that framework winds up making it easier to create needed
variations.  If that smart pointer class is unwieldy because it tries to be
too many things, then there should be more classes.

The bottom line is that there should be a means by which few ever have to
write smart pointers again.  We should supply the class(es) that do all of
the reasonable things out of the box or via sensible, understandable
configuration.

That's not to say there shouldn't be some standard typedefs for common
variations.  std::shared_ptr and std::auto_ptr might be typedefs that
configure std::smart_ptr a certain way.  If warranted, they could be
separate classes.

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

There can be no argument with that.  I would put a different spin on it
though: it is a reasonable goal to create a single framework that does
everything, if it is workable and sensible.  *If* that doesn't work, *then*
we should consider which other class or classes is needed.  That's not
trying to "assimilate the competition."  Rather, it's trying to simplify or
at least streamline the toolset one must use or master for the common and
even the uncommon cases.

Rob
Susquehanna International Group, LLP
http://www.sig.com

IMPORTANT:The information contained in this email and/or its attachments is
confidential. If you are not the intended recipient, please notify the
sender immediately by reply and immediately delete this message and all its
attachments.  Any review, use, reproduction, disclosure or dissemination of
this message or any attachment by an unintended recipient is strictly
prohibited.  Neither this message nor any attachment is intended as or
should be construed as an offer, solicitation or recommendation to buy or
sell any security or other financial instrument.  Neither the sender, his or
her employer nor any of their respective affiliates makes any warranties as
to the completeness or accuracy of any of the information contained herein
or that this message or any of its attachments is free of viruses.