🚀 go-pugleaf

In article <1990Oct18.230000.14131@twinsun.com> eggert@ata.twinsun.com (Paul Eggert) writes:
>Is the sequence
>
>	// a co\
>	mment
>
>a legal comment in ANSI C++?  ANSI C's translation phases are as follows:
>
>	1.  Trigraphs are replaced by non-trigraph equivalents.
>	2.  backslash-newline pairs are removed
>	3.  The file is decomposed into preprocessing tokens and white space
>	    (including comments).
>	...
>
>If C++ is like ANSI C here, then it seems that the above sequence must be a
>legal C++ comment.


According to ELLIS, Margaret A., STROUSTRUP, Bjarne, "The Annotated C++
Reference Manual", pp 370ff, [Chapter 16, section 1]:

	1.  If needed, new-line characters are introduced to replace
	    system-dependent end-of-line indicators and any other
	    necessary system-dependent character set translations
	    are done.  Trigraph sequences are replaced by their single
	    character equivalents.
	2.  Each pair of backshash character \ immediately followed by
	    a new-line is deleted, with the effect that the next source
	    line is appended to the line that contained the sequence.
	3.  The source text is decomposed into preprocessing tokens and
	    sequences of white space.  A single white space replaces
	    each comment.  A source file may not end with a partial
	    token or comment.
	...

So, yeah,

		// This is a comment \
		   though a rather useless one.

is a legal comment.  God help me if I know why you'd ever want to *use*
such a construction...
--
	William Edward Woody		   | Disclamer:
USNAIL	P.O.Box 50986; Pasadena, CA 91115  |
EMAIL	woody@tybalt.caltech.edu	   | The useful stuff in this message
ICBM	34 08' 44''N x 118 08' 41''W	   | was only line noise. 

eggert@ata.twinsun.com (Paul Eggert) writes:

>Is the sequence
>	// a co\
>	mment
>a legal comment in ANSI C++?  ANSI C's translation phases are as follows:

There is no such thing as ANSI C++ yet, and indeed this is one of the
issues which must be resolved by the ANSI C++ (X3J16) committee.  There
was a heated debate on this very point in comp.lang.c++ (I think) some
months ago.  Different C++ compilers currently treat this differently.
To be safe, do not use //-style comments with continued lines.  Use /* */
comments instead.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com

In article <1990Oct19.165355.28351@nntp-server.caltech.edu> woody@tybalt.caltech.edu (William Edward Woody) writes:
>...God help me if I know why you'd ever want to *use*
>such a construction...

I believe the main reason given for generalizing backslash-newline -- which
used to be just for string continuation -- was to help programs that build
or filter C source and want to limit line length.  Given this, it is
important that you be able to cut a line *anywhere* with backslash-newline,
so that such programs don't have to do full tokenizing just to decide where
it's legal to break a line.
-- 
The type syntax for C is essentially   | Henry Spencer at U of Toronto Zoology
unparsable.             --Rob Pike     |  henry@zoo.toronto.edu   utzoo!henry

In article <484@taumet.com> steve@taumet.com (Stephen Clamage) writes:
>eggert@ata.twinsun.com (Paul Eggert) writes:
>
>>Is the sequence
>>	// a co\
>>	mment
>>a legal comment in ANSI C++?  ANSI C's translation phases are as follows:
>
>There is no such thing as ANSI C++ yet, and indeed this is one of the
>issues which must be resolved by the ANSI C++ (X3J16) committee.  There
>was a heated debate on this very point in comp.lang.c++ (I think) some
>months ago.  Different C++ compilers currently treat this differently.
>To be safe, do not use //-style comments with continued lines.  Use /* */
>comments instead.

While there may be no ANSI C++ standard, the Anotated C++ Reference manual
clearly states the phases of translation, thus resolving this question
(they are the same as ANSI C). Since ARM was written as the base document
for the ANSI committie you could in an abstract sense consider it the ANSI
standard.

The need for a standard, in my opinion, stems not so much from ambiguities in 
ARM (which are very hard to find), but from the fact that compiler writers
treat an ANSI standard with much more respect than they do the language authors
specification. This leads to different compilers not treating issues like
line splicing correctly.
--
Dave Scidmore, Heurikon Corp.
dave.scidmore@heurikon.com