RE: [boost] Smart pointer poll

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-05-14 17:30:35

On Sunday, May 05, 2002 7:59 AM, Peter Dimov [SMTP:pdimov_at_[hidden]] wrote:
> From: "David B. Held" <dheld_at_[hidden]>
> > I would like to see people comment on the various questions:
> >
> > 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 don't care how it's spelled, but I'm interested in seeing the policy-based
smart pointer and a good, reasonable, default smart pointer type[def] that
gives decent results for the users that don't want to pay attention to the
details.

> 3a. Should there be a single smart pointer type that is
> specifically
> designed for interoperability?

Having a single type[def] that works pretty well for most cases means that
various libraries can interoperate while avoiding glue code and data
copying. That's a worthwhile goal.

> 3b. Should there be a single smart pointer type that is
> specifically
> designed to cover a variety of common situations without
> requiring any user
> intervention or customization?

If there isn't, many users won't use them. However, that doesn't mean that
it can't be a type with all but one template parameter defaulted. There's
good precedent in Standard C++ for this: char_traits and allocators are
rarely specified. Thus, defaulting some number of template parameters won't
put off today's C++ programmer.

> 3c. Is shared_ptr (the specification) the single smart pointer
> that meets
> 3a, 3b, or both?

It seems pretty good.

> 3d. If it is, which is the best way to provide a smart pointer
> that meets
> that specification?
> 
> A) shared_ptr<T>, implementation details unspecified

There's nothing wrong with that, that I can see. That can even be a template
typedef specializing the framework class template.

> B) shared_ptr<T>, implementation required to be derived from a
> general
> pointer framework

I don't see why you would need to require this implementation. You could
require that it behave "as if" it were derived from the framework class
template.

> C) ptr<T>::shared

I like this approach, but, as you've pointed out, it doesn't allow the
compiler to deduce T in function calls.

> D) smart_ptr<T> (defaulted parameters)

I think that's fine.

> E) smart_ptr<T, default_config>

That would be fine if "default_config" were the only template parameter and
it was defaulted (which I see as a variation of D, where D specifies
"parameters" not "parameter"). It would also be fine if there was a template
typedef naming that specialization "shared_ptr."

> F) smart_ptr<T, A, B, C, D>

I concur with Dietmar: this is definitely not acceptable.

> 3e. Allow me to sneak a personal question. Should I bother with
> refining
> shared_ptr (the semantics) any further? I'd rather cut my
> losses now, to be
> blunt.

As Dietmar said, the semantics are valuable in their own right and deserve
to be matured fully. If there's work to be done to refine those semantics,
then by all means continue. Whether your shared_ptr survives or its
semantics are subsumed by a policy-based approach is less important.

> > 1. Is a policy-based smart pointer still worth pursuing, or
> > are there too
> > many
> > contentious issues that will never get resolved?
> 
> The answer to this political question is probably "yes."

It is certainly worth pursuing. Whether it proves to be the accepted
approach remains to be seen.

> I'd rather see a (concise) answer to the following questions
> instead:
> 
> 1a. Why is a smart pointer framework a good thing?

Yes. We already know that customized smart pointers are not uncommon. If a
framework can make those customized smart pointers easy, if not trivial, to
implement, then it is worthwhile. The alternative is for customized smart
pointer developers to look at and copy existing practice to create new ones.
Using the framework means that bug fixes to the framework automatically fix
all smart pointers based upon it. If each smart pointer is handcrafted, then
each must be checked for the problem and each must be corrected, if
necessary.

> 1b. What are the design goals of the framework?

- Factor out common code, with the attendant maintenance benefit
- Standardize interface (which could be specified in the standard without a
framework, of course)
- Simplify creating specialized, custom smart pointers

> 1c. What user problems does this framework address?

Which user? The person inclined to create a new smart pointer type will find
it easier to create a new type -- provided the third goal, above, is
achieved. The person using a smart pointer won't care either way if there
are reasonable defaults or there is a suitable typedef available.

> 1d. How does the framework compare with other solutions to the
> user problems
> in 1c?

I think I've covered this above. If not, ask for more.

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.