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

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-05-02 17:42:18

From: Peter Dimov [mailto:pdimov_at_[hidden]]
> 
> From: "Gennadiy Rozental" <rogeeff_at_[hidden]>
> > "Peter Dimov" <pdimov_at_[hidden]> wrote
> >
> > > shared_ptr<T>'s custom deallocator support deliberately 
> doesn't use
> > another
> > > template parameter to avoid this possibility.
> >
> > You keep repeating this argument, but I still do not see why is it
> > important.
> 
> 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.

One way to make it prettier is through a typedef.  Obviously, we need
template typedefs to do that and we can use the struct hack to get around
that.  Then again, we're discussing the smart pointer functionality that
should be part of the standard, and it's pretty clear we'll see template
typedefs at the same time.

Another way to make it prettier is to default the policies.  Still another
way is to use a traits class parameter -- defaulted if you like -- that
specifies the interoperability policies.  Finally, you can make it prettier
by using the adapter policy approach: having a single policy dictate a
collection of other policies.  This is rather like using a traits class
parameter to specify the policies.

There are probably other ways to make the spelling easier and prettier, but
it comes down to spelling, doesn't it?

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

> The problem is not policy-specific. It's about degrees of freedom.

Which can be restricted without abandoning policies.

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.