Xref: utzoo comp.lang.c++:10331 comp.std.c++:415
Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!decwrl!sgi!shinobu!odin!sgi.com!linton
From: linton@sgi.com (Mark Linton)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: const is not object-oriented
Message-ID: <1990Nov12.184240.23430@odin.corp.sgi.com>
Date: 12 Nov 90 18:42:40 GMT
References: <1990Nov9.181408.23110@odin.corp.sgi.com> <13050@cadillac.CAD.MCC.COM>
Sender: news@odin.corp.sgi.com (Net News)
Reply-To: linton@sgi.com (Mark Linton)
Organization: sgi
Lines: 55

All the responses so far have essentially said the same thing:
"we don't care what const really means, we'll use it how we want".
I understand the motivation, but this is a bit dangerous.
If a compiler puts a static life-time const in read-only storage and
you use a cast to write into that storage, you'll get a memory fault
(speaking from experience here).

It seems clear that const doesn't provide the semantics that many programmers
(including me) want.  We can

    (1) continue to abuse its meaning as many are already,
	using casts to circumvent compiler attempts to enforce the meaning

    (2) change the meaning of const to remove the storage semantics

    (3) find another way to do what we want

(1) is just an informal convention for (2), where the programmer uses
casts to get around the fact that the compiler thinks const has more meaning.
(2) would change const to be a simple subtyping mechanism in that
only const member functions can be used on const objects.  Const would
no longer mean anything with respect to storage.

(3) is a useful exercise to consider.  I can imagine a value for a notion
of const storage, for things like read-only data or vectorizing compilers,
so I'm against (2).  (1) is dangerous because users of classes
will not realize that class designers are not using const as
it is specified.  If the C++ community is really adopting (1), we should
at least put a pragma in the interfaces so that compilers and users
can be aware of this convention.

It seems like the desired behavior of (2) could also be achieved
by defining "const" member functions in a base class and
non-const functions in a subclass.  This is the general mechanism
we use when we want to separate which member functions can be used
in different circumstances.  It is curious that for the case of const
behavior programmers seem to want (need?) another language mechanism.

By the way, for those who couldn't reproduce my cfront problem,
it turns out to be a bit subtler than I realized.  The program below
demonstrates the bogus warning, but if the A(int) constructor
is removed then no warning is generated.  I suppose this should just
be classified as another one of those mysterious cfront bugs.

class A {
public:
    A();
    A(int);

    void f(A&);
};

void g(A& a) {
    a.f(A());
}