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

From: scleary_at_[hidden]
Date: 2002-10-02 10:38:56

> -----Original Message-----
> From: Yitzhak Sapir [mailto:yitzhaks_at_[hidden]]
> 
> > -----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?

If it's const, the compiler can assume its value doesn't change. There are a
few exceptions the compiler has to watch out for (e.g., const casting), but
this is the general idea behind value propogation and loop strength
reduction.

> > . 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.

Agreed.

So why redefine const scoped_ptr to mean something *completely* different?
We would only be asking for confusion...

> 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 don't know about the deleter function question.  But the
scoped_dynamic_cast one is easy: there is no assignment of scoped pointers.

> > 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.

f(T *); // no ownership concept at all
f(scoped_ptr<T> &); // ownership may be transferred
f(const scoped_ptr<T> &); // no ownership transfer

Thus, f(scoped_p) might or might not lose ownership; this depends on the
interface of f().

Scoped pointers may not actually be passed to or returned from functions,
while auto_ptrs can be. It is possible to add the same workarounds used for
auto_ptr to scoped_ptr, but if you're going to pass or return a scoped_ptr
to or from a function, then you really need a smart pointer that is capable
of transferring ownership -- that is, auto_ptr.

The functions above (and the ones starting this thread) pass *references* to
scoped pointers.

        -Steve