Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!ucbvax!agate!saturn!skinner
From: skinner@saturn.ucsc.edu (Robert Skinner)
Newsgroups: comp.lang.c++
Subject: Re: C++ Comments
Summary: AT&T C++ uses /lib/cpp
Message-ID: <7611@saturn.ucsc.edu>
Date: 23 May 89 04:24:26 GMT
References: <6957@brunix.UUCP> <24700@agate.BERKELEY.EDU> <2900@pegasus.ATT.COM>
Organization: U.C. Santa Cruz, CIS/CE.
Lines: 36

In article <2900@pegasus.ATT.COM>, hansen@pegasus.ATT.COM (Tony L. Hansen) writes:
> <>Consider the following C++ source line:
> <>
> <>    //**********************
> <>
> <>How should this be treated by the C++ compiler?  The GNU g++ compiler
> <
> <    If the input stream has been parsed into tokens up to a given character,
> <    the next token is taken to include the longest string of characters which
> <    could possibly constitute a token.
> <
> <g++ is doing the right thing, and the AT&T compiler is wrong.
> 
> Actually, the problem is with the C preprocessor being used with the cfront
> compiler, not with the AT&T compiler. The G++ preprocessor deals with //
> comments. Whatever vendor supplied your port of cfront should have also used
> a preprocessor which understands // comments.

the AT&T compiler uses /lib/cpp, which knows nothing about the //
comment.  This is great for portability, every C compiler has a 
preprocessor.

Unfortunately, it is a royal PAIN when using a package like 
curses that uses lots #define macros.  You can't put the name of 
the macro in a // comment, e.g.
	// this routine uses move
or
	// move the object down

without getting an argument mismatch error from cpp.

Such is the price we pay for portability and 
building on previous tools.

Robert 
skinner@saturn.ucsc.edu