From: Schoenborn, Oliver (Oliver.Schoenborn_at_[hidden])
Date: 2002-10-04 11:29:54
> On Friday 04 October 2002 16:58, Schoenborn, Oliver wrote:
> > A smart pointer IS-NOT-A pointer either.
> No it is a drop in replacement. And as such it has to model
> pointer behaviour.
*If* it is a drop-in replacement, I can't argue with that. I didn't think
shared_ptr was (actually, I don't think any smart pointer could).
> > So although all of the above is
> > true, from a *usage* point of view there is no difference to the
> > (though of course to the compiler writer the difference differences are
> > critical): a const smart_ptr for T should be usable wherever one for
> > T can be used.
> No, definetly not. There is a difference for builtin pointers
> between a const
> pointer and a pointer to const objects and so should be for any smart
I know, and that's not what I meant. I meant that, you can give a
pointer-to-non-const to a function expecting a pointer-to-const. The fact
that this is implemented in terms of temporaries etc matters if you want to
bind to refs, e.g. Similarly, you should be able to give a "smart pointer to
non-const" object to a function expecting a "smart pointer to const".
However, for safety, you must allow that only if the function is not going
to modify the pointer.
> If it does not behave like a pointer it should not be named pointer.
AFAICT C++98 does not provide some critical mechanisms that would allow for
the creation of a class that can perfectly mimic, i.e. behave like, a
pointer. At best, it mimics certain important characteristics thereof. As
well, since the const stuff discussed above applies to pointers, it should
apply to smart pointers, according to your above statement.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk