Re: error: passing `const Weight' as `this' argument of `float Weight::wgt()' discards qualifiers

Ruben <ruben@www2.mrbrklyn.com> kirjutas:


No, it will not, and that's the point of the const system. It holds your
hand and tries to prevent you shoot in your leg.

Some people argue that constness it not the only or most important aspect
to keep in mind when working with objects, and there should be no
obligation to use it. However, it has been built into the language (in
signatures of assignment op and copy ctor and the rule about binding
temporaries to const references) as well as into the standard library, so
practically there is no alternative to making all code const-correct from
the start.

Here, the standard signature for assignment op is as you wrote:

Weight& Weight::operator=(const Weight &fweight);

The constness of the argument now propagates further to every use of the
fweight reference. I try to explain the propagation mechanism in more
detail, feel free to use your books instead if I am not making any sense
;-)

The signature promises that inside this function the fweight argument is
kept const. Now you are calling function fweight.wgt() which is non-const
and thus may potentially modify the object referenced by fweight. Thus
the compiler cannot be sure it can keep up with the promises of operator=
() signature, so the compilation is aborted.

Now, if you make wgt() const,

class Weight {
     public:
        float wgt() const { return wgt_; };

Now the operator=() is happy and compiles. OTOH, if you had called some
non-const member function on the same object from wgt(), you would have
got another error there, i.e. the error will also "propagate". Now you
could add 'const' to this next member function and see if the thing
compiles, etc.

However, making the code const-correct this way is quite tedious, better
is to decide up-front which member functions should not modify the
object, and mark them 'const' from the start. The "getter" functions like
wgt() are the obvious candidates.

hth
Paavo