Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!mailrus!cornell!uw-beaver!tektronix!orca!radio_flyer!paulsc
From: paulsc@radio_flyer.WV.TEK.COM (Paul Scherf;685-2734;61-028;;orca)
Newsgroups: comp.lang.c++
Subject: Re: "//" comments and #define's : problems
Summary: Here's how I did it.
Keywords: C++ style comments
Message-ID: <3860@orca.WV.TEK.COM>
Date: 12 Jul 89 16:13:13 GMT
References: <1000019@hpclscu.HP.COM>
Sender: nobody@orca.WV.TEK.COM
Reply-To: paulsc@radio_flyer.WV.TEK.COM (Paul Scherf)
Distribution: usa
Organization: Tektronix, Inc., Wilsonville, OR
Lines: 44

In article <1000019@hpclscu.HP.COM> shankar@hpclscu.HP.COM (Shankar Unni) writes:
>When fixing up a "cpp" to handle "//"-style comments, I came across an
>interesting problem.

>Comments on #define's are preserved by cpp when sucking up the define, and
>later, after substitution, subsequent rescans of the line simply strip out
>the comment. (This is how it makes token-pasting, etc work).
...
>This is an intrinsic problem with "//"-comments on #defines, because if you
>use the "pass comments" option on cpp (usually -C on sysV-based systems),
>the same thing will happen (you'll get stage two above, and then cfront
>will strip out the "y" token).

>Question:

>How should a "//"-comment on a #define work?

>  (a) Completely stripped out when processing #define. Not passed through
>      even when requesting "pass comments". (This is my preference).

On the C compiler I wrote for my homebrew system, cpp doesn't perserve
comments on #defines when sucking up the define, unless the "pass
comments" option is used.  I decided this was probably ok.  I don't
particularly like the token pasting syntax specified in ANSI C, but I
can live with that, when I need to paste tokens together.

>  (b) Leave it as is. I.e. specify that a "//"-comment on a #define will
>      have "undefined" (i.e. nasty and unpredictable) effects. Warn the
>      user when detected.

This is what Bjarne Stroustrup says C++ should do in his book "The C++
Programming Language" (I only know about one edition) on page 130.  I
think my scheme limits the nasty and unpredictable effects, to
programmers who are trying to be tricky (e.g. using the "pass comments"
option).

>  (c) Do some fudge like have "cpp" insert a "/*" and "*/" around the
>      "//"-style comment, as in

>      x b /* // comment */ y

I considered this, but I rejected it when I discovered that an old
C-style comment (/* ... */) can't always comment a new C++-style
comment (// ... ).