Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!usc!apple!voder!procase!roger
From: roger@procase.UUCP (Roger H. Scott)
Newsgroups: comp.lang.c++
Subject: Re: Is this legal?
Message-ID: <179@logo.procase.UUCP>
Date: 20 Jul 90 06:25:05 GMT
References: <10164@odin.corp.sgi.com> <PCG.90Jul17114203@odin.cs.aber.ac.uk>
Reply-To: roger@procase.UUCP (Roger H. Scott)
Organization: proCASE Corporation, Santa Clara, CA
Lines: 31

In article <PCG.90Jul17114203@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
>...
>	Always prefix 'this->' to any reference to a member in a member
>	function body, and similarly for all the other scope indicators.
The extra clutter of "this->" isn't really necessary.  The same effect
(of disambiguating references to various scopes) can be achieved with lexical
conventions such as naming all data members myFoo and myBar.  There isn't
any risk of conflict with file scope identifiers, because the only file scope
identifiers are class names and they are always spelled ClassName, right? :+}

>
>	Always write first all data members, then all the functions
>	member delcarations, even if you are allowed not to.
If we assume the usual convention that things that appear ahead of other
things (in the order they are read) are more important then I would think
we would want to put the public interface (functions) ahead of the private
information (data), not vice versa.  When I am scanning a class definition
I would rather not see the data *at all* - it is unfortunate that C++
requires that data be declared in the publicly visible class definition.

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

    struct S { int myR; };
    struct T {int f(); int myS;};
    inline int T::f() {return myS;}