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

From: David Abrahams (dave_at_[hidden])
Date: 2002-10-02 06:09:18

----- Original Message -----
From: "Yitzhak Sapir" <yitzhaks_at_[hidden]>

>
>
> > -----Original Message-----
> > From: Henrik Ravn [mailto:web_at_[hidden]]
>
> > How about simply having two versions of operator->() :
> >
> > T* shared_ptr<>::operator->(); // like it is now
> >
>
> The current signature is:     T * operator-> () const // never throws
>
> > > Even though this does not implement technically correct semantics, I
> > > believe that it fulfills the practical semantics of most
> > > usage.  That is, it
> > > seems extremely unlikely that shared_ptr<T> const is stored
> > as data by
> > > very many people.  It seems that the most likely appearance of
> > > shared_ptr<T> const is in a function signature, where the
> > > user probably
> > > also would like T to be const.  My proposal is technically
>
> One situation I can think of: If your object contains a map to
shared_ptr's of T, (meaning, you don't own the T's but have easy access to
them -- not a rare situation), then a const function couldn't access the
map other than with const_iterator's, which means the T's you'd see would
be const.  This may not be desired.  The const in the function declaration
only means your function does not touch the object as regards the object
and the things it owns.  It is not supposed to mean pointers to objects
with shared ownership, which you don't own.
>
> I suggested having an impl_ptr, that acts like a scoped_ptr but has const
and non const operator-> and operator*.  Now I am thinking, why shouldn't
scoped_ptr act like that?  I'd think passing scoped_ptr's as const&
arguments is not something that common or that should even be promoted.

Why is everyone barking up this tree instead of using shared_ptr<T const>
"as god intended"?

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com