Re: const is an overrated concept that is a source of extra typing and maintenan
On Mar 26, 12:29 am, brang...@cix.co.uk (Dave Harris) wrote:
matthew.b...@l-3com.com (mattb) wrote (abridged):
I have recently heard the above, along with a further statement
along the lines of -
'const is there to stop amateur slip ups. Professionals should know
what a function is expecting and should use that.'
Could I please have some comments on these statements.
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.
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.
Cheers,
Mark.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]