Path: utzoo!attcan!ncrcan!scocan!jfischer
From: jfischer@sco.COM (Jonathan A. Fischer)
Newsgroups: comp.lang.c++
Subject: Re: operator++()   and   testing 'this'
Message-ID: <1990Oct9.144542.19983@sco.COM>
Date: 9 Oct 90 18:45:42 GMT
References: <706@msor0.UUCP>
Sender: news@sco.COM (News)
Organization: SCO Canada, Inc. (formerly HCR Corporation)
Lines: 42
Nntp-Posting-Host: hal

In article <706@msor0.UUCP> kt@msor.UUCP (Keith Tizzard) writes:
>Two questions about C++
>
>1   operator++()
>
>a = ++b;
>a = b++;
>
>Is it not possible for the usual arrangement whereby the ++ is
>performed before = in the first, and after it in the second?

	To answer your question: Yes!  Now in cfront 2.1, if you define

	X::operator++()

it's a prefix ++.  If you define

	X::operator++(int dummy)

it's a postfix ++.  (If the second form isn't defined, the first form will
be used for both).  I'm not sure why they leave it up to the programmer to
handle the pre-/post-ness, rather than just having the compiler translate
	a = b++;
into
	a = b; (void)b.operator++();
Anyone, anyone...?

>2   Testing of and assigning to 'this'
>
>Is it still possible to assign to 'this' in V2.0?

	Technically, you can't assign to this, since it's "X * const this".
BUT, it's listed in Appendix B.3.3 as an "anachronism," something that is
provided for compatibility with earlier releases of cfront.  I.e., you can do
it, but technically you shouldn't.  Also, there is no requirement for a
compiler vendor to implement these anachronisms, so you are tainting your
portability by using them.

>Can one rely on 'this' having the value zero on entry to the constructor
>if the object is allocated on the free store?

	Yep, according to the same anachronisms section.