RE: [boost] [smart_ptr] const-correctness as function argument

From: Yitzhak Sapir (yitzhaks_at_[hidden])
Date: 2002-10-02 10:52:29

> -----Original Message-----
> From: scleary_at_[hidden] [mailto:scleary_at_[hidden]]

> I often use const as:
> . A hint to the compiler's optimizer

How can the compiler optimize a scoped_ptr?  My understanding was that in most cases the compiler cannot optimize based on const, but simply the selection of const vs. non const implementations can lead to optimizations.

> . A hint to other programmers
> 
> so:
>   const scoped_ptr<T> x(..);
> means:
>   The pointer object 'x' will *always* point to the same 
> object that it is
> constructed with here.  It will not be reset() to be null, or 
> to point to
> another object.
> but does *not* mean:
>   The object being pointed to is const

So does const auto_ptr<T> x(..);
It turns out that const auto_ptr and const scoped_ptr both mean almost the same thing.
For a moment I thought scoped_ptr takes a bit more space because you can specify a deleter function.  I guess it doesn't let you do that, and takes up the same space.  Why this asymmetry between shared_ptr and scoped_ptr?  Also, why aren't there scoped_dynamic_cast and friends?

> I am not in the general habit of passing scoped_ptr's to 
> functions, but if I
> did, I would expect:
>   void f(const scoped_ptr<T> &);
> to mean:
>   f() cannot change the value of the pointer object
> not:
>   f() cannot modify the object being pointed to

Is it desirable to allow or support the passing of scoped_ptr's to functions?  Both f(scoped_p.get()) and f(scoped_p) must assume that scoped_p does not lose ownership.  I think this is usually guaranteed (because the scoped_ptr is based on scope), unless 
1) the very rare and probably very undesirable case that someone does delete p; or const_cast<>(scoped_p).reset() somewhere in f(),
and 2) unless someone uses a function that returns scoped_ptr reference declared in an unrelated object (or in a function running in a different thread), and passes that value on.  In this case, it is up to the user to guarantee that the scope of the pointer is longer than the scope of the function call.  This is true either using scoped_p.get() or scoped_p.