Re: const is an overrated concept that is a source of extra typing and mai
markjord@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! ]