Xref: utzoo gnu.g++.bug:1516 comp.lang.c++:6601
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!pcg
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: gnu.g++.bug,comp.lang.c++
Subject: Re: g++ 1.36.3 bug
Summary: Member functions? NO THANKS! :-)
Message-ID: <1657@aber-cs.UUCP>
Date: 22 Feb 90 13:42:25 GMT
Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Followup-To: comp.lang.c++
Distribution: gnu
Organization: Dept of CS, UCW Aberystwyth
	(Disclaimer: my statements are purely personal)
Lines: 43

In article <25E0AC9A.28299@paris.ics.uci.edu> rfg@ics.uci.edu (Ronald Guilmette) writes:
  
  There seem to be a lot of problems with the implementation of "const"
  functions both in cfront (2.0) and in g++ (1.36.1).

Do away with member functions entirely! (my pet peeve, as rfg knows :->).
The problem is not with the implementation; it is with the contortions
you need to get through to handle the 'hidden' this parameter. For the
millionth time, let me say that if functions whose first parameter were
a reference or pointer to a class object could be called in infix
notation, all this, and a good many other problems, would be drastically
simplified.
  
  	#1) It makes absolutely no semantic sense to allow global (i.e.
  	    non-member) functions to be declared as `const', and yet both
  	    cfront and g++ allow such function to be defined.

One of the many quirks of building a language as a collection of special
cases.. Are you sure that the famous ugly red book allows only member
functions to be const? Maybe there is a reserve such as 'global const
means no side effects'. Bohhhhhh.
  
  	#2) If two otherwise identical forms of a global function with a
  	    given name are defined (with one being `const' and one not)
  	    g++ at least gives an error for conflicting definitions.  cfront
  	    says nothing.

Bleech.
  
  	#3) If two otherwise identical member functions (or operators) with the
  	    same "designator" are declared and defined for a given class
  	    (with one being const and the other one not) neither g++ nor
  	    cfront seem to mind  (although one could argue that they should).
  	    There is some sense in which this could be considered a legal
  	    overloading based upon the consness or non-constness of the
  	    implicit `this' parameter.

As far as I remember from the Primer, this is indeed the case in C++ 2.0;
it is even encouraged programming practice.
-- 
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk