herman@kulcs.uucp (Herman Moons) (07/23/90)
Why does the C++ language demand that the programmer states which
member functions are const ?? This seems a job for the compiler, not
for the programmer (after all, the compiler checks whether a function is
really const if we specify it that way).
I guess the const keyword is needed to tell the compiler about the const'ness
of a member function when it is invoked for a const class object (the member
function is perhaps implemented in another file, where the compiler cannot
see it).
But why not encode the const-info into the function name, just like the
parameter type info ?? A member function f that is const (which can be
determined by the compiler) could than be given two entries in the symbol
table, one with and one without the const-info.
e.g. f T 0xaaaaa --- entry 1
C_f T 0xaaaaa --- entry 2
When a non-const object calls f(), entry 1 is looked up. When a const object
calls f(), a call for C_f is made. When the member function was not const,
the C_f info would not have been generated, and a link error would occur.
Without the const keyword, errors would also be catched (at link time, and
not at compile time). So why bother the programmer with these technicalities.
What really bothers me about const member functions is that one must provide
the compiler with information that he already knows.
Any opinions on this topic ??
herman
-----------------------------------------------------------------------------
Herman Moons Katholieke Universiteit Leuven
Dept. of Computer Science
Tf : +32 (16) 20.06.56 Celestijnenlaan 200A
Fax: +32 (16) 20.53.08 B-3030 Heverlee-Leuven
Belgium
e-mail: herman@kulcs.uucp
herman@blekul60.bitnet
herman@cs.kuleuven.ac.be
-----------------------------------------------------------------------------mat@mole-end.UUCP (Mark A Terribile) (07/24/90)
In article <2026@kulcs.kulcs.uucp>, herman@kulcs.uucp (Herman Moons) writes: > Why does the C++ language demand that the programmer states which > member functions are const ?? This seems a job for the compiler, not > for the programmer (after all, the compiler checks whether a function is > really const if we specify it that way). > What really bothers me about const member functions is that one must provide > the compiler with information that he already knows. > Any opinions on this topic ?? Only that the programmer can write overloads based on the const-ness, and that this is sometimes a desirable thing to do. I'm not entirely happy with the meaning of const as applied to class types, since there is the (by now) too-often repeated question of whether the const shoud indicate that the object in memory is const or that the ``thing'' which it represents is const. No, I don't know the answer. -- (This man's opinions are his own.) From mole-end Mark Terribile
steve@taumet.com (Stephen Clamage) (07/24/90)
herman@kulcs.uucp (Herman Moons) writes: >Why does the C++ language demand that the programmer states which >member functions are const ?? This seems a job for the compiler, not >for the programmer (after all, the compiler checks whether a function is >really const if we specify it that way). You might want two versions of a member function, depending on whether it deals with a constant object. You have to declare one of them const, since you cannot declare the "this" pointer at all. When you invoke one of these functions, the compiler picks the right one (overload resolution) based on whether the object is const. When there is only one member function with a given signature, the compiler could in principle determine whether any assignments were possibly made to the object, and classify the object as const. This would make part of the function type invisible, requiring every user of this function to read and correctly understand the details of the function code before knowing how to call it. Having a program fail to link as the only diagnostic of this problem seems like a poor idea. -- Steve Clamage, TauMetric Corp, steve@taumet.com
steve@taumet.com (Stephen Clamage) (07/25/90)
I wrote: >When there is only one member function with a given signature, the >compiler could in principle determine whether any assignments were >possibly made to the object, and classify the object as const. ^^^^^^ should be "function", not "object". sorry. -- Steve Clamage, TauMetric Corp, steve@taumet.com
carroll@paul.rutgers.edu (V. I. Lenin) (07/25/90)
herman@kulcs.uucp (Herman Moons) asks: >Why does the C++ language demand that the programmer states which >member functions are const? 1. For all the same reasons you declare the "const" in the following: void f(const T *); 2. Because classes have both abstract state and concrete state. In line with the constant goal of raising the level of abstraction in programs, the "const" keyword on a member function should always be used to mean "this member function does not change the abstract state of the object." Unfortunately, C++ defines "const" to mean "this member function does not change the concrete state of the object." (Cfront isn't dumb, it simply has no way of knowing what the "abstract state" of your class is.) Since it is possible for a member function to change the concrete state of an object without changing the abstract state, in order to implement the desired (abstract) meaning of const, the programmer must use a cast in such situations: class T { int i; public: T(); void f() const; // means f doesn't change abstract state }; void T::f() const { // ... T *This = (T*)this; ++This->i; // ... } Here T::i is a data member whose value doesn't functionally affect the abstract state of T. Notice that the above cast is guaranteed to work, since C++ mandates that classes with constructors be placed in writable store. -- martin
bright@Data-IO.COM (Walter Bright) (07/26/90)
In article <2026@kulcs.kulcs.uucp> herman@kulcs.uucp (Herman Moons) writes:
<Why does the C++ language demand that the programmer states which
<member functions are const ?? This seems a job for the compiler, not
<for the programmer (after all, the compiler checks whether a function is
<really const if we specify it that way).
The function body may not be available in the compilation unit where the
call to the function occurs, so the compiler cannot determine if the function
is const or not.
<But why not encode the const-info into the function name, just like the
<parameter type info ?? A member function f that is const (which can be
<determined by the compiler) could than be given two entries in the symbol
<table, one with and one without the const-info.
< e.g. f T 0xaaaaa --- entry 1
< C_f T 0xaaaaa --- entry 2
<When a non-const object calls f(), entry 1 is looked up. When a const object
<calls f(), a call for C_f is made. When the member function was not const,
<the C_f info would not have been generated, and a link error would occur.
An interesting idea! One problem comes to mind. If I call a member function
with a non-const object, then I call x->f(). Unfortunately, now the compiler
optimizer must *assume* that the contents of x are changed. If I explicitly
call x->C_f(), then the optimizer is guaranteed that the contents of x are
unchanged by the call, leaving many optimization possibilities open.
<What really bothers me about const member functions is that one must provide
<the compiler with information that he already knows.
I believe the real problem here is the fact that the typical C++ compiler
methodology is that of separate compilation. A number of things in the
language could be much cleaner if not for the desire to support the
separate compilation implementations.
Another issue is the one of redundancy. Most high level languages have a
lot of redundancy in them. An example is expressions being terminated with
a ; in C. The ; is not really necessary, the parser can nearly always
determine where it should go. Occaisionally you will hear proposals to
elminate the ;. But it's nice to have, because the redundancy makes error
detection, diagnosing and recovery much easier for the compiler, and it
also provides redundancy to anyone visually reading the code.
A language with no redundancy in it would be *extremely* difficult to
debug, because then nearly anything is a valid program (to the compiler)!
Nglsh s ls a vry rdndnt lngg, s vdnc f ths yu cn rd ths!sagar@ese.essex.ac.uk (Sagar V) (09/11/90)
I am looking for information on Real-time Embedded Software in C++. Has anyone out there worked on Real-time Embedded Software in C++ ? Please reply to me personally, my email address is sagar@uk.ac.essex.