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