Re: const is an overrated concept that is a source of extra typing and maintenan
mtspark wrote:
On Mar 26, 12:29 am, brang...@cix.co.uk (Dave Harris) wrote:
The title comment is a reasonable point of view. Although const has
benefits, it also adds a lot of complexity to the language. It's not just
the "const" keyword itself, you also have const_cast<> and mutable, and
issues like whether *p should be const if p is const (sometimes it should,
sometimes it shouldn't). The extra typing includes the need to write a
const_iterator as well as a non-const one, and in general the common need
to double-up interfaces in order to preserve or propagate const. It's a
lot of work.
Exactly, you have to have a pretty solid argument for it to add such a
burdern to programmers!
IMO the additional complexity is not worth the price paid, especially
when the 'const' concept is fundamentally broken to begin with.
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.
Huh? By the above "const", the caller knows that calling doesn't change
the logical state of IAbstract, which is quite a guarantee. Whether that
is *correct* or not is a matter of the design of IAbstract, and of
course the one to know whether that is correct or not is the provider of
the interface.
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.
Quite the opposite. It (C++) has no means to express "physical"
const-ness. It is just that logical const-ness coincides with physical
const-ness in some simple cases (like, the const-ness of "int").
Adding const here violates the very principles of OO; encapsulation
and information hiding.
Huh? Quite the opposite. Adding const here hides *how* you implement
MethodA() and whether the object is internally changed in some way or
another. It expresses that "you shouldn't care" how it's made, but any
type of change that might or might not happen behind the curtains
doesn't matter to the caller or the interface. That, exactly, is the OO
principle.
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!
Exactly. That is why const is *not* physical const-ness.
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.
Exactly - const may provide optimization opportunities, but that is not
what is const is made for.
So long,
Thomas
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]