From: Dave Harris on
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
benefit anyway.

-- Dave Harris, Nottingham, UK.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]