Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!zaphod.mps.ohio-state.edu!usc!jarthur!uunet!mcsun!ukc!dcl-cs!aber-cs!odin!pcg
From: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.lang.c++
Subject: Re: Is this legal?
Message-ID: <PCG.90Jul17114203@odin.cs.aber.ac.uk>
Date: 17 Jul 90 10:42:03 GMT
References: <10164@odin.corp.sgi.com>
Sender: pcg@aber-cs.UUCP
Organization: Coleg Prifysgol Cymru
Lines: 74
In-reply-to: jfw@rome.wpd.sgi.com's message of 10 Jul 90 17:31:29 GMT


In article <10164@odin.corp.sgi.com> jfw@rome.wpd.sgi.com (john fergus
wilkinson) writes:

   Is this legal C++? [ ... slightly rewritten example follows ... ]

	struct s { ... };
	struct t { int f() { return s; }; int s; };

This should work. The reference to 's' in 'return s' is clearly a
reference to 't::s', not to the 's' class name. There is a rule that
requires member function bodies defined in a class definition to be
considered only after all of the class definition has been seen, and
therefore 't::s' hides 'struct s' within 't'.

Of course you did not follow my fundamental and all important guidelines
to avoid these amboguities, and two of which I will summarize here:

	Never define a memeber fucntion in a class definition, but
	always separately and after the class definition.

	Always prefix 'this->' to any reference to a member in a member
	function body, and similarly for all the other scope indicators.

	Always write first all data members, then all the functions
	member delcarations, even if you are allowed not to.


Exampe, rewritten:

	struct s { int r; };
	struct t { int s; int f(); };
	int t::f() { return this->s; }

This is unambiguous (mostly -- for the sake of brevity I have not put in
storage class idnicators, etc...), most importantly to the human reader.

Let me repeat here my usual tirade about the difference in attitude
between European (algorithmic language) and USA (programming language)
ideas of the role of programs and languages:

	Programs for Europeans are there to communicate the
	implementation of an algorithm,	either to programmatic
	(e.g. compilers, pretty printers, verifiers) or human (even
	more important!) readers. As such it should be as clear and
	unambiguous as possible, and as informative as it can be without
	becoming hard to read because of verbosity.

	The USA position is that programs are there to drive a
	computer to perform a task, and as long as they "work", who
	cares...

   As I read the discussion in Section 9.9 of Ellis and Stroustrup,
   this should be illegal under the rule "A class-name...may not be
   redefined in a class declaration after being used in the class
   declaration..."  Am I right?

I have difficulty understanding what this phrase exactly means, frankly.
Probably it means that you cannot do the following:

	struct s { ... };
	struct t { s u; int s; };

i.e. use it as both as a type name and a field name (reasonable
constraint). Of course this must still be legal and can be used to get
around the constraint:

	struct t { struct s u; int s; };

but then I would regard this as unclear programming practice.
--
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk