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

From: Yitzhak Sapir (yitzhaks_at_[hidden])
Date: 2002-10-02 06:26:17

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