RE: [boost] Smart pointer poll

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-05-15 08:45:02

From: Peter Dimov [mailto:pdimov_at_[hidden]]
> 
> From: "Stewart, Robert" <stewart_at_[hidden]>
> >
> > > 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.
> 
> Yes, of course. It _can_ be a template with defaulted parameters. The
> question is: _must_ it be a template with defaulted 
> parameters? Why is a
> template with defaulted parameters better?

Ah, I didn't understand that's what you wanted to ask.  In and of itself,
no, a template with defaulted parameters isn't better than a specific class.

> > 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.
> 
> The char_traits/allocator precedent is a very good example, 
> and you can draw
> all sorts of conclusions from it. ;-)

Understood.

> > > 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.
> 
> The alternative is included because people have expressed this opinion
> during the debate. (Beman's summary seems to imply that some 
> LWG members
> feel the same way.) I presume that their reasoning is: if the 
> C++ standard
> library includes a smart pointer framework, then the other 
> standard smart
> pointers should be derived from the framework as a proof of concept.

I think it is reasonable to say that the implementation should be "as if"
derived from the framework with certain policies.  That leaves the
implementation open to any whims of the implementer while elevating the
framework.  Still, if the framework isn't good enough for the
implementation, it does leave doubts about the framework, doesn't it?

> > > 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.
> 
> This doesn't actually apply to the standard library. Fixing 
> bugs in the
> standard library (design) takes time. A standard framework 
> must be bug free.

Not quite.  If there's a bug in the *implementation* of the framework,
rather than with the design of the framework, my comment applies (and that,
of course, is what I had in mind).  Still, your point is valid: if the
design of the framework is flawed, it will take a long time to correct it.

> > > 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
> 
> Looks almost obvious; that's probably the reason that nobody cared to
> answer. :-) Implementing smart pointers is a common task 
> (t/f?); these smart
> pointers share common code (t/f? which code?); therefore, a standard
> framework can help (t/f? is implementing a policy easier than 
> implementing a
> pointer using editor inheritance?).

Were you agreeing with my statement or questioning each of the points?

> Note how these design goals say nothing about auto_ptr and 
> shared_ptr. Do
> they fit the "common code" pattern? They might, but this 
> should be carefully
> thought out and not just accepted as an axiom.

I certainly agree with that.  However, we do need to consider whether the
framework can be designed to subsume those semantics.  That is, whether we
replace auto_ptr and shared_ptr with a framework specialization is not as
important as a framework that can do the same things.  (OK, auto_ptr's
unique copy semantics may be a challenge, and may be sufficiently unique
that we could ignore it in the framework.  That remains to be seen.)

> > > 1c. What user problems does this framework address?
> >
> > Which user?
> 
> The user of the framework, not the user of the user of the 
> framework. :-)

To wipe away a bit of the mud from the windshield, you're asking what
problems the framework solves for smart pointer creators, not for smart
pointer users, right?  I think we've covered them pretty well above.
Implicit in the factorization of common code is eliminating most sources of
error, which is highly valuable.

Your questions are good: they focus on goals and value.  The question
remains whether a policy-based smart pointer framework is superior to other
means to achieve the goals.  It has to be sufficiently valuable to be the
preferred -- or at least the default -- means of creating new smart
pointers, or it isn't worthwhile.

Andrei's experience with Loki::SmartPtr suggests that the framework approach
is valuable, workable, and beneficial.  That alone means we need to pursue
the framework idea, even if our conclusion is that it isn't appropriate for
standardization.  Add to that the new ideas for improving on SmartPtr and
you have the makings of a very good framework that very well may be
appropriate for the standard.

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.