|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-05-15 09:10:41
From: "Stewart, Robert" <stewart_at_[hidden]>
> Still, if the framework isn't good enough for the
> implementation, it does leave doubts about the framework, doesn't it?
Good question, and the answer is not obvious. I have never seen a
custom-made smart pointer that's even close to auto_ptr or shared_ptr (the
current spec); so it is not clear to me that a framework that makes it
easier to build custom-made smart pointers should cover auto_ptr or
shared_ptr.
> > 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.
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_.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk