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

From: Ed Brey (brey_at_[hidden])
Date: 2002-10-02 08:42:37

"Yitzhak Sapir" <yitzhaks_at_[hidden]> wrote in message news:7647A9F4B298E74DB6793865DA67285003B7AD_at_exchange.adrembi.com...

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

Just off the top of my head, consider a class that represents a community.  The community may or may not have a fire station, but whichever way it is, it is always that way.

class Community {
 public:
    Community(auto_ptr<FireStation>& fs): fireStation(fs) {}

    void RemodelFireStation() { // Remodels the fire station, if any:
        if (_fireStation)
            _fireStation->Remodel();

        _fireStation.reset(); // Bug caught by compiler.
    }

private:
    scoped_ptr<FireStation> const _fireStation;
};

Here constness of the member works like it does for any member pointer.  It prevents the program from accidentally changing the value of the pointer.  Actually, the scoped pointer takes the protection one notch further: it prevents the object being pointed to from accidentally being destroyed via reset().

Disallowing _fireStation from being changed would be undesirable.  It would undermine the granularity of protection provided by the current difference between these types:

scoped_ptr<T> const
scoped_ptr<T const>
scoped_ptr<T const> const