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

From: scleary_at_[hidden]
Date: 2002-10-02 08:52:36

> -----Original Message-----
> From: Yitzhak Sapir [mailto:yitzhaks_at_[hidden]]
> 
> 1) Usually I declare my classes as
> class some_class
> {
>   ...
> private:
>   class impl;
>   boost::scoped_ptr<impl> m_impl;
>   ...
> };
> 
> It seems to me more natural that the implementation class of 
> the class belongs to the class rather than sits outside of 
> it.  Using this, it becomes harder to use a pimpl_base.  I 
> also think having those two lines is a little clearer than 
> inheriting from pimpl_base (but just a little).

As you mention in your second point, changing pimpl_base to a scoped_ptr
adapter isn't difficult.

> 2) I know I can write an adaptor for scoped_ptr to do this 
> (calling it impl_ptr or whatever).  I suggested it before, 
> and I'll probably do it soon for myself.  This post, I was 
> thinking that since a scoped_ptr is the owner of the data, 
> const functions on the pointer should give const data.  Maybe 
> I'm just wrong or missing something :)  But since passing 
> scoped_ptr's as an argument may be rare (passing p.get() may 
> be a better option), is there really a need to have a 
> operator->()const (and operator*() const) that returns a 
> non-const T? (Even a rare use-case would suffice for me to 
> convince me it's wrong to have them in scoped_ptr, I was just 
> suggesting something).

I often use const as:
. A hint to the compiler's optimizer
. 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

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

In general, most smart pointer classes just have less suprising behavior
when they follow "const rules" similar to raw pointers.

        -Steve