RE: [boost] Smart pointer poll

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

From: Peter Dimov [mailto:pdimov_at_[hidden]]
> 
> From: "Stewart, Robert" <stewart_at_[hidden]>
> 
> > > 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?
> 
> A little bit of both. What I am questioning is the 
> "axiomatic" mindset that
> takes the answers to the above questions for granted; I think that the
> answers are far from obvious, and an objective analysis ("A case for
> policy-based smart pointers" paper) will help in focusing the 
> debate and
> break the unfortunate stalemate we've got ourselves into.

Let me clarify my answers to those questions.

1. Is implementing smart pointers a common task?

It depends on what you mean by "common."  I or someone else has created at
least one smart pointer at every company I've worked for.  Some are
single-minded (RAII), others more ambitious (class template with policies
back when I thought they were traits classes!).

2. Do these smart pointers share common code?

Most of the code is common for most smart pointers.  What typically differs
is how to allocate, if at all, how to deallocate, if at all, and how to
copy.

3. Can a standard framework help?

If the answer to the first two questions is yes, then the answer to this one
is probably yes, too.  Loki::SmartPtr has proven the utility of the idea.
The other benefit, as I've mentioned before, is that a framework, however
implemented, improves maintenance.

4. Is implementing a policy easier than implementing a pointer using "editor
inheritance?"

Given that the inheritor must know all about the smart pointer s/he is
copying in order to know where the changes should be made, the answer is
"yes."  By isolating changes to individual policy classes, the developer
creating a new smart pointer type can focus on implementing only the
portion(s) of the smart pointer behavior that make the new type unique.

> To reiterate, my own position is that shared_ptr<> and a 
> policy-based smart
> pointer can coexist, do not compete with each other since they solve
> different problems, and will have value _even if they don't 
> interoperate_.

I agree that the two can coexist.  I don't agree that they solve different
problems, though that may yet be shown.  I agree that the two have value
even if they don't interoperate, as will std::auto_ptr.

It remains to be seen if a policy-based smart pointer is the silver bullet
for smart pointer design.  It may be, as you've pointed out, that a
framework would be overburdened to provide for the semantics of
std::auto_ptr and boost::shared_ptr.  Then again, it may not.  I think that
a framework is worthwhile.  I don't know that a policy-based smart pointer
class template is that framework, though it looks promising.

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.