RE: [boost] Re: [smart_ptr] const-correctness as function argumen t

From: Schoenborn, Oliver (Oliver.Schoenborn_at_[hidden])
Date: 2002-10-04 11:29:54

> Oliver,
> 
> 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
programmer
> > (though of course to the compiler writer the difference differences are
> > critical): a const smart_ptr for T should be usable wherever one for
const
> > 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 
> pointer.

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.

Oliver