Re: const is an overrated concept that is a source of extra typing and maintenan

Using const for constants and some optimisation is fine, but to trying
to take it any further to object interfaces is fundamentally flawed.
For all you const proponents, perhaps you can shed some light on this
little design issue?

I have an abstract interface, lets call it IAbstract with a single
method, lets call it MethodA. Let's say this interface has two
implementations, one for windows and one for linux.

class IAbstract
{
    public:
       virtual int MethodA() const = 0;
};

Is it correct to declare MethodA const as above? My answer is that
with c++ you cannot possibly know because you cannot predict what
needs to be done within the two implementations.

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.

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.

If you
were going to specify const anywhere for optimisation purposes, it
should be within the method implementation, not in the method
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.