cardboard.mti.sgi.com!sgi.sgi.com!uu3.psi.com!asbestos!wstewa (Wayne Stewart) writes:

|>  >>>>> "JK" == James Albert Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:
|>    JK>
|>    JK> Making // comments mask the end of line would make them almost
|>    JK> unusable in #define's.
|>    JK>
|>
|>  As it is they're barely usable in multi-line #define's, i.e., you only
|>  get to use 1 // comment and by definition it has to be at the end of
|>  your macro.  That's not really conducive to heavily commenting your
|>  macros.  (Of course, code macros aren't really conducive to writing
|>  good C++ :-)

True.  But this is a normal consequence of declaring that macros are
terminated at the end of the line: if a macro is, by definition, a
single line, then it is normal that a comment to end of line can only
come at the end of it.

In fact, I beleive that there was some discussion of this in the
committee, and in fact, I think that some compilers will terminate a //
comment at an escaped newline.

|>  Aren't // comments being added to ISO/ANSI C, though?

I think so.

|>  Will they be adding inline functions as well?

This is debatable.  As has been pointed out in comp.std.c, ISO C
currently has one form of inline function, compatible with earlier
definitions of inline non-member functions in C++; the keyword to
declare such a function is "static".

For the record: despite appearances, the actual meaning of "inline" in
C++ is *NOT* to tell the compiler to generate the function inline.  A
compiler is never required to generate a function inline; on the other
hand, it can generate any function it likes inline, as long as the
program semantics are maintained.  What "inline" does do is allow you to
define the function in multiple compilation units, without invoking
undefined behavior (unless the definitions are not identical).

The support in the compiler/linker for multiple definition of functions
with extern linkage is non trivial; it is interesting to note that
almost all of the early C++ compilers got it wrong, at least if the
address of the function was taken (the address taken in two different
modules must compare equal), and generally when the function contained
local static variables as well.  Since much of this support is necessary
for templates, and since to be useful in C++, inline functions must be
allowed with extern linkage (since member functions have extern
linkage), the extra weight in the compiler is acceptable.  In C, on the
other hand, it represents considerable new effort.  Without member
functions, requiring inline functions to be static is an acceptable
restriction.  But since the compiler can already inline whatever it
wants, the inline keyword then ends up having exactly the same meaning
as static.

--
James Kanze         home:     kanze@gabi-soft.fr        +33 (0)3 88 14 49 00
                    office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg, France
       -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Wayne Stewart wrote:
>
> One could perhaps envision a "special case" in which // comments
> would eat backslash-newline combinations but not unescaped newlines,
> so that you could do the following:
>
>     #define CODE_MACRO(param)                           \
>         <some code>             // a comment            \
>         <some more code>                                \
>         <still more code>       // another comment      \
>         <last of the code>
>
>     #define LITERAL_MACRO <value>       // a comment
>     <code>
>
> Of course, this prevents being able to continue a // comment onto the
> next line with backslash-newline, but whatthehey.
>

What is the current draft spec re: backslash splicing and comment
conversion?
Which comes first?

--

- Rick Hollinbeck (rickh@westernwares.com)
  Web: http://www.westernwares.com/
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article 500E@westernwares.com, Rick Hollinbeck
<rickh@westernwares.com> writes:
>
>What is the current draft spec re: backslash splicing and comment conversion?
>Which comes first?

The "phases of translation" were carefully worked out by the C Committee
to give the expected results in all the usual circumstances. The C++
Committee did not modify them, except for adding a few fairly minor
features unique to C++.

People try to make the issue of comments too difficult. It's really not.
The first three phases go like this for both C and C++, leaving out a
few C++ nits:

1. Map physical characters in the external file to internal representation
   and convert trigraphs to their single-character internal equivalents.
   (In particular, ??/ gets converted to \ in this phase, meaning you can
   still escape a newline if you don't have \ in your character set.)

2. Splice physical lines separated by escaped newlines into single
   logical lines. (This means you can split tokens, including string
   literals, across physical lines.)

3. Decompose the file into a sequence of preprocessing tokens and
   whitespace, converting each comment into one blank character.

In C, a comment starts with /* and ends with */. In C++, a comment also
can start with // and end at the next newline. Since escaped newlines have
already been processed, there is no ambiguity. A comment is a comment,
and is removed in phase 3, after line splicing.

We don't have //-comments currently in C, so the C++ rules don't cause
any incompatibility. The C++ rules mean that you probably don't want
to use //-comments on a physical line that ends with an escaped newline.
There are no other questionable interactions.

Escaped newlines, it seems to me, are common only in complicated
macro definitions, or in machine-generated code. (Human-written code
tends to break lines between, not within, tokens, and has little need
for escaped newlines.) One exception would be string literals continued
onto several lines, but they can't contain internal comments anyway.

Two simple guidelines should eliminate any problems:
1. Use /*...*/ comments instead of //-comments in macro definitions.
   (Complicated macros are not usually needed in C++ anyway.)
2. If machine-generated code might contain escaped newlines other than
   in string literals, have the machine generate /*...*/ comments
   instead of //-comments.
The guidelines are stronger than necessary, but are easy to remember
and apply, and should not cause any difficulty.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Hi,
Steve Clamage (stephen.clamage@eng.sun.com) wrote:
: We don't have //-comments currently in C, so the C++ rules don't cause
: any incompatibility.

Interesting. I always though that the following program gives different
results whether you have //-comments (C++) or do not have them (C)
while still being both a legal C and C++ program:

  int main()
  {
    int i = 17;
    i = i //* who would put a comment like this? */
        -1;
    return i;
  }

Depending on whether you have //-comments, this program returns -17 (C)
or 16 (C++).  I would rate this an incompatibility but AFAIK,
//-comments will be in the next ISO C standard, too, removing this
incompatibility. Also, I would not write source like this but then, I
wouldn't do a lot of other at first sight strange things either...
--
<mailto:dietmar.kuehl@uni-konstanz.de>
<http://www.informatik.uni-konstanz.de/~kuehl/>
I am a realistic optimist - that's why I appear to be slightly pessimistic
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

stephen.clamage@eng.sun.com (Steve Clamage) writes:

|>  In C, a comment starts with /* and ends with */. In C++, a comment also
|>  can start with // and end at the next newline. Since escaped newlines have
|>  already been processed, there is no ambiguity. A comment is a comment,
|>  and is removed in phase 3, after line splicing.

I think that the "ambiguity" originally referred to resides in the
definition of a comment, in 2.7, where it says: "The characters /* start
a comment, which terminates with the characters */. [...] The characters
// start a comment, which terminates with the next new-line character."

The wording is exactly the same for both the /* and // style comments.
We know that the terminating */ is part of the /* style comment, and
eliminated when the comment is replaced by the single space character in
phase three.  The parallelism in the expressions defining the comments
would suggest that this is also true of the new-line character (which is
still significant in phase 3) of the // style comment, so that in:

    #define x ab // comment
    cd

the value of x becomes "ab cd".

Given the history of C++, and what I know about other languages, I feel
certain that this is not what was intended, and to tell the truth, until
the initial posting in this thread, the thought never occured to me.
Still, I can see now how someone might read it this way.  It probably
wouldn't hurt if some words were added in 2.7 to make it clear that the
/* comment is inclusive the "*/", but the // exclusive the new-line.

--
James Kanze         home:     kanze@gabi-soft.fr        +33 (0)3 88 14 49 00
                    office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg, France
       -- Conseils en informatique industrielle --


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article 3@news.belwue.de, kuehl@kalkofen.informatik.uni-konstanz.de (Dietmar Kuehl) writes:
>Steve Clamage (stephen.clamage@eng.sun.com) wrote:
>: We don't have //-comments currently in C, so the C++ rules don't cause
>: any incompatibility.
>
>Interesting. I always though that the following program gives different
>results whether you have //-comments (C++) or do not have them (C)
>while still being both a legal C and C++ program: ... [ example deleted ]

You took my remark out of context. The article discussed comments and
escaped newlines. The C++ phases of translation regarding comments
and escaped newlines are compatible with the current C rules. That is,
a program that is both valid C and C++ looks the same after phase 3
of translation (external-to-internal format and trigraph conversion,
splicing escaped newlines, removal of comments and tokenizing).

---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

asbestos!wstewa@uu3.psi.com (Wayne Stewart) writes:

|>  Given the following cpp macro definitions:
|>
|>  #define two \
|>  1\
|>  /* multi-line
|>     C-style
|>     comment */+ 1
|>
|>  #define one_or_three \
|>  1\
|>  // C++-style comment
|>  + 1\
|>  // another C++-style comment
|>  + 1
|>
|>  the preprocessor (GNU cpp included w/ gcc/g++) replaces
|>  'two' with '1 + 1 ', but replaces 'one_or_three' with
|>  '1 '.  (Apparently the first // comment in a multi-line
|>  cpp macro ends the macro.)
|>
|>  My question is:  is this behavior consistent with the
|>  draft standard?

It is the only behavior which would be consistent, at least
traditionally.  A C++ style comment extends to the end of line, but does
not mask out the end of line.

|>  Some statements I found in the April 95 Working Paper
|>  related to this question are:
|>
|>   1) "Each comment is replaced by one space character.
|>       New-line characters are retained."  (?)

This seems perfectly clear with regards to // comments.  It would seem
to suggest, however, that the first #define should end in the middle of
the comment, which is obviously impossible.

|>   2) "The characters /* start a comment, which terminates
|>       with the characters */."
|>
|>   3) "The characters // start a comment, which terminates
|>       with the next new-line character."
|>
|>  If I read statement (3) the same way I read statement (2),
|>  I would get the impression that the newline character is
|>  part of the comment itself, which gets replaced with a
|>  space, and should not therefore terminate the macro
|>  definition.

I agree that perhaps the wording could be improved, although I think
most people would not have trouble guessing what is wanted.  Making //
comments mask the end of line would make them almost unusable in
#define's.  On the other hand, /* ... */ comments do mask end of lines
in C, and one could hardly imagine any reason for doing things
differently in C++.

--
James Kanze         home:     kanze@gabi-soft.fr        +33 (0)3 88 14 49 00
                    office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg, France
       -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

>>>>> "JK" == James Albert Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:
  JK>
  JK> Making // comments mask the end of line would make them almost
  JK> unusable in #define's.
  JK>

As it is they're barely usable in multi-line #define's, i.e., you only
get to use 1 // comment and by definition it has to be at the end of
your macro.  That's not really conducive to heavily commenting your
macros.  (Of course, code macros aren't really conducive to writing
good C++ :-)  Aren't // comments being added to ISO/ANSI C, though?
Will they be adding inline functions as well?

One could perhaps envision a "special case" in which // comments
would eat backslash-newline combinations but not unescaped newlines,
so that you could do the following:

    #define CODE_MACRO(param)    \
 <some code>  // a comment  \
 <some more code>    \
 <still more code> // another comment \
 <last of the code>

    #define LITERAL_MACRO <value> // a comment
    <code>

Of course, this prevents being able to continue a // comment onto the
next line with backslash-newline, but whatthehey.

I would never think of proposing a modification to ANSI C++ to
accommodate the preprocessor.  However, this issue is pretty much
isolated to cpp, so I doubt whether such a change would impact many
compilers (with the exception of those for which preprocessing is not
a separate phase).

As things stand, I would append Scott Meyers' "Effective C++" Item #4
to say "Prefer C-style comments with ALL uses of #define".

Thanks,

    Wayne Stewart
    wstewa@atl.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Hi,

Given the following cpp macro definitions:

#define two \
1\
/* multi-line
   C-style
   comment */+ 1

#define one_or_three \
1\
// C++-style comment
+ 1\
// another C++-style comment
+ 1

the preprocessor (GNU cpp included w/ gcc/g++) replaces
'two' with '1 + 1 ', but replaces 'one_or_three' with
'1 '.  (Apparently the first // comment in a multi-line
cpp macro ends the macro.)

My question is:  is this behavior consistent with the
draft standard?

Some statements I found in the April 95 Working Paper
related to this question are:

 1) "Each comment is replaced by one space character.
     New-line characters are retained."  (?)

 2) "The characters /* start a comment, which terminates
     with the characters */."

 3) "The characters // start a comment, which terminates
     with the next new-line character."

If I read statement (3) the same way I read statement (2),
I would get the impression that the newline character is
part of the comment itself, which gets replaced with a
space, and should not therefore terminate the macro
definition.

(I know cpp is evil and one should use constants, inline
functions, etc. when working in C++, but lets ignore all
that for now, especially since // comments may be (are ?)
included in ISO standard C.)

Thanks,
    Wayne Stewart
    wstewa@atl.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]