[comp.lang.c++] C++ releases from AT&T?

guido@cwi.nl (Guido van Rossum) (03/30/88)

Here in Europe it seems to be hard to get a recent release of AT&T's C++
translator.  "Unix Europe Ltd." tell me that the latest release they've
got is 1.2 (back from 1986) and that we'll have to wait for 2.0 until at
least this summer.  I find this hard to believe.  Could somebody in the
US comment on the availability there?

NB: this concerns an educational licence.  Also, I'm not yet interested
in G++ (until there is a well-debugged back-end for the tahoe
architecture).

PS: I asked about the official status of unreachable code elimination by
the translator earlier, but didn't get useful replies (I don't think
replies along the lines of "G++ also does this" answer my question about
whether this is part of the language, in some sense).  So, anybody care
to comment on the question of what happens to code after
"if (constant-expression-evaluating-to-zero) ..." ?

--
Guido van Rossum, Centre for Mathematics and Computer Science (CWI), Amsterdam
guido@cwi.nl or mcvax!guido or (from ARPAnet) guido%cwi.nl@uunet.uu.net

bright@Data-IO.COM (Walter Bright) (03/31/88)

In article <254@piring.cwi.nl> guido@cwi.nl (Guido van Rossum) writes:
<I asked about the official status of unreachable code elimination by
<the translator earlier, but didn't get useful replies.
<So, anybody care
<to comment on the question of what happens to code after
<"if (constant-expression-evaluating-to-zero) ..." ?

The code should be deleted in any optimizing compiler. A compiler that
readsanexpression/generatescodeforexpression cannot simply delete it, because
there may be labels in the then-expression.

In my C++ compiler (and my C compiler), any control flow where the compiler
can figure out which branch will always be taken is optimized. I also believe
this is an implementation issue, not a language issue.

nevin1@ihlpf.ATT.COM (00704a-Liber) (03/31/88)

In article <254@piring.cwi.nl> guido@cwi.nl (Guido van Rossum) writes:

>PS: I asked about the official status of unreachable code elimination by
>the translator earlier, but didn't get useful replies So, anybody care
>to comment on the question of what happens to code after
>"if (constant-expression-evaluating-to-zero) ..." ?

I don't know what the *official* status on "if
(constant-expression-evaluating-to-zero) ..." is, but at least on our
translator, it seems to eliminate it (see below).

I wrote a little test program:

/********************************************************************/
void	exit(int);

int	main()

{
if (1-1)
	exit(1);	//unreachable
exit(0);
}
/********************************************************************/

which cfront 1.2.3 translated into the following:

/********************************************************************/
/* <<cfront 1.2.3 7/21/87>> */
/* < test.c */
char *_new(); char _delete(); char *_vec_new(); char _vec_delete();

char exit ();

int main (){ _main(); 
{ 
;

exit ( (int )0 ) ;
}
};

/* the end */
/********************************************************************/


Hope this helps,
-- 
 _ __			NEVIN J. LIBER	..!ihnp4!ihlpf!nevin1	(312) 510-6194
' )  )				"The secret compartment of my ring I fill
 /  / _ , __o  ____		 with an Underdog super-energy pill."
/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah

guido@cwi.nl (Guido van Rossum) (03/31/88)

I wrote:
<anybody care to comment on the question of what happens to code after
<"if (constant-expression-evaluating-to-zero) ..." ?

and bright@Data-IO.COM (Walter Bright) replies:

>I also believe this is an implementation issue, not a language issue.

This is the crux.  I want it to be a language issue, so I can replace
90% of the occurrences of
	
	#ifdef DEBUG
		printf("We did it!!!!!!!!!!\n");
	#endif

by

		if (debug) printf("Did it...\n");

which is much less disturbing for the reader of the code.
It can be controlled by a variable or a constant, e.g.:

	#ifdef NDEBUG
	const debug = 0;
	#else
	int debug; /* Set by -D command line flag */
	#endif

However, I need some reassurance that turning on NDEBUG will actually
remove all these debug lines from my code.  A wording similar to that
used for the descriuption of 'inline' would be fine: the intention is
clear, and compiler writers should attempt to honor it if reasonably
possible.

--
Guido van Rossum, Centre for Mathematics and Computer Science (CWI), Amsterdam
guido@cwi.nl or mcvax!guido or (from ARPAnet) guido%cwi.nl@uunet.uu.net

rsalz@bbn.com (Rich Salz) (04/01/88)

guido@cwi.nl (Guido van Rossum) starts talking about what if (0) ...
means to optimizing compilers, and is this a language issue or an
implementation issue.

bright@Data-IO.COM (Walter Bright) replies that it's an implementation
issue.

("It's a dessert topping."  "It's a floor wax."  [Sorry Guido, US Television
reference.])

Guido reponds,
>  I want it to be a language issue, so I can replace
>90% of the occurrences of
>	#ifdef DEBUG
>		printf("We did it!!!!!!!!!!\n");
>	#endif
>by
>		if (debug) printf("Did it...\n");
because that's much easier to read.

He'd also like it to be able to do this:
>	#ifdef NDEBUG
>	const debug = 0;
>	#else
>	int debug; /* Set by -D command line flag */
>	#endif

I think his last request really proves that it's an implementation
issue.  What should happen if I do this:
	prompt% adb -w a.out
	_debug/W 1
	$q
	prompt% 
-- 
Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.

jee@teddy.UUCP (John E Elsbree) (04/01/88)

In article <257@piring.cwi.nl> guido@cwi.nl (Guido van Rossum) writes:
>This is the crux.  I want it to be a language issue, so I can replace
>90% of the occurrences of
>	
>	#ifdef DEBUG
>		printf("We did it!!!!!!!!!!\n");
>	#endif
>
>by
>
>		if (debug) printf("Did it...\n");
>
>which is much less disturbing for the reader of the code.

You can accomplish this in another way that is equally undisturbing...

	#ifdef DEBUG
	#define DBG(x) x
	#else
	#define DBG(x)
	#endif
	    .
	    .
	    .

	  DBG(printf("We did it!!!\n"));

If you use this method, the preprocessor throws away all your debugging
code if you don't define DEBUG.
--
John E Elsbree                 GenRad, Inc.
...!mit-eddie!genrad!jee       300 Baker Avenue
(617)369-4400 ext 2935         Concord, MA 01742, USA

karl@haddock.ISC.COM (Karl Heuer) (04/08/88)

In article <570@fig.bbn.com> rsalz@bbn.com (Rich Salz) writes:
|He'd also like it to be able to do this:
|>	#ifdef NDEBUG
|>	const debug = 0;
|>	#else
|>	int debug; /* Set by -D command line flag */
|>	#endif
|
|I think his last request really proves that it's an implementation
|issue.  What should happen if I do this:
|	prompt% adb -w a.out
|	_debug/W 1
|	$q
|	prompt% 

I think that if you want the program to be able to handle that sort of
tweaking, you should have declared debug with the "volatile" keyword.  (In
other words, I believe that in the absence of "volatile", the compiler should
be free to assume that you *won't* do that.)

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint