From: Dave Harris on 9 Apr 2010 06:16
markjord(a)gmail.com (mtspark) wrote (abridged):
> In one implementation, Method A may just return a copy of the
> instance variable. Fine, const fits here. In another implementation,
> the underlying object state (perhaps another state variable) may
> have to change to get the answer. ie. The interface is logically
> const but the implementation is non-const. What should you do in
> this situation? C++ doesn't seem to distinguish between logical
> and physical constness.
Const on member functions represents logical const. Here the function
would be const and the variable that needs to change would be mutable.
So it's not really a problem for C++, but it is a complication that
anyone dealing with const needs to deal with.
> Adding const here violates the very principles of OO; encapsulation
> and information hiding. You should not care what happens inside the
> object, the interface is there to shield you from the details.
It doesn't violate those principles, because both classes would have the
same, const, interface.
> Also, I reckon if a c++ compiler wants to do optimisations, it
> should be smart enough to do them some other way - and in fact
> having to tell the compiler every little thing is a ball-ache
> and probably stems from compiler writers wanting to take the
> easy route out, comes as no surprise to me really lol.
Const is rarely useful for optimisations in C++. Partly because of the
above: ie usually it conveys information about the interface, not the
implementation, and optimisations usually need the implementation.
In addition, usually the compiler /is/ smart enough to figure it out for
itself whether something can change. If it can't, that usually means so
much code is involved that the optimisation wouldn't have significant
-- Dave Harris, Nottingham, UK.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]