Brian Sullivan (brians@cup.hp.com) wrote:
: I believe that the back-slash should have no special meaning within
: a comment.

: I have tried this test program with several different C++ compilers.
: Both gcc and HP C++ compiler have the problem.  The  USL cfront
: compiler doesn't have the problem.

: Is there an official ruling on this issue in the C++ Standard.

:  -- Brian --

 I just read section r.16.1 Phases of Preprocessing.  Apparently the
flaw has been designed into the language.  Sigh.  Can anyone give me
a rational for this horrible decision.  I ran into this problem when
I was coding a character scanner table which looked somthing like
this:

charClass charClassOf[256] = {
   CcIllegalChar,  // 0x00  NUL
   ...
   CcUppercaseLetter,  // 0x5a  Z
   CcOpenSquareBracket,  // 0x5b  [
   CcBackSlash,   // 0x5c  \
   CcCloseSquareBracket, // 0x5d  ]
   ...
}

Of course I want to initialize this table with exactly 256 entries
and I would like to have the comment at the end of the line help to
show which charcter is being initialized.  It's not much fun if the
C++ compiler decides that the entire line following the back-slash
new-line sequence is part of the comment on the previous line.

Of course C++ doesn't give you an error for this case it simply
initializes 255 entries and zeros out the last entry.  The program
works for a while until it accesses a value  higher than back-slash
and then it breaks. Sigh. I wish there was a way to force the
compiler to require that every element in the array be initialized
and I want an error if only 255 initialization are provided.

 -- Brian --

  The following program demonstrates a bug with the pre-processor:

main( // \
)
{
}

The pre-processor allows the sequence back-slash new-line to extented
the C++ style comment across the line break, thus turning the 2nd
line into a comment.

The output from the pre-processor using -E show the problem.

% gcc -E foo.C
# 1 "foo.C"
main(

{
}

I believe that the back-slash should have no special meaning within
a comment.

I have tried this test program with several different C++ compilers.
Both gcc and HP C++ compiler have the problem.  The  USL cfront
compiler doesn't have the problem.

Is there an official ruling on this issue in the C++ Standard.

 -- Brian --

brians@cup.hp.com (Brian Sullivan) writes:

>Brian Sullivan (brians@cup.hp.com) wrote:
>: I believe that the back-slash should have no special meaning within
>: a comment.


> I just read section r.16.1 Phases of Preprocessing.  Apparently the
>flaw has been designed into the language.  Sigh.  Can anyone give me
>a rational for this horrible decision.


C++ uses the same phases of translation as C. It is hard enough to
specify how preprocessing works without trying to contend with
two different sets of rules.

Since the sequence backslash-newline is processed before comments
are looked for, the next physical line becomes part of the // comment.

Two cautions:
1. Avoid macros.
2. Never use //-comments in a preprocessor line. Use /**/ comments.

("Doctor, it hurts when I do this." "So don't do that.")
--
Steve Clamage, stephen.clamage@eng.sun.com

brians@cup.hp.com (Brian Sullivan) writes:

>  The following program demonstrates a bug with the pre-processor:
>
>main( // \
>)
>{
>}
>
>The pre-processor allows the sequence back-slash new-line to extented
>the C++ style comment across the line break, thus turning the 2nd
>line into a comment.

It's not a bug, it's a feature.

>I believe that the back-slash should have no special meaning within
>a comment.

This is an issue on which reasonable people can differ.

>I have tried this test program with several different C++ compilers.
>Both gcc and HP C++ compiler have the problem.  The  USL cfront
>compiler doesn't have the problem.
>
>Is there an official ruling on this issue in the C++ Standard.

We don't have a standard yet, but ANSI/ISO working paper is
quite clear on this point (see section 2.1).
The USL cfront compiler is broken, and gcc and HP C++ are correct.

--
Fergus Henderson - fjh@munta.cs.mu.oz.au
all [L] (programming_language(L), L \= "Mercury") => better("Mercury", L) ;-)