Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!samsung!dali.cs.montana.edu!milton!uw-beaver!entropy!dataio!bright
From: bright@Data-IO.COM (Walter Bright)
Newsgroups: comp.lang.c++
Subject: Re: const member functions: why bother the programmer?
Message-ID: <2591@dataio.Data-IO.COM>
Date: 25 Jul 90 18:18:54 GMT
References: <2026@kulcs.kulcs.uucp>
Organization: Data I/O Corporation; Redmond, WA
Lines: 46

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!