In light of the accepted answer pointing out that returning a non-const reference to a member from a const instance method won’t compile (without a cast or making the member variable mutable), the question has become more a general best-practices discussion of const instance methods.
For posterity, here’s the original question:
If I have an object with a getter that returns a non-const reference, for example:
SomeObject& SomeOtherObject::foo(){
return someObjectInstance;
}
Should this be made const? Obviously the call itself doesn’t modify the object, but the caller could then modify someObjectInstance which would mutate my instance of SomeOtherObject.
I guess my question really boils down to “what exactly does const on a member method mean?” Is it A) the call itself won’t mutate the object or B) no mutation of the object can occur during the call, or as a result of the returned references/pointers (with a caveat for people who do const_casts).
As an aside, I’m currently adding this where I need const calls.
const SomeObject& SomeOtherObject::constFoo() const{
return someObjectInstance;
}
to be on the safe side, since I’m reluctant to do
SomeObject& SomeOtherObject::foo() const{
return someObjectInstance;
}
even though it would make my life easier in some places.
const (when applied to a member function) is mainly useful as a means of self documenation. It is a contract with the calling code that this function will not modify the external state (i.e. have no observable side effects).
The compilier achieves this by making all members effectively const while inside a const member function
It is not uncommon to see code like:
The following won’t compile (MSVC 9 and gcc 3.4.4)
You could hack around the above error by casting away the const:
but this of course breaks the contract with the users of your code that you won’t be changing the SomeOtherObject instance.
You could also make someObjectInstance mutable to be able to avoid the cast, but in the end it really isn’t any better.