> > > "Nicola Musatti" <nicola.musatti@objectway.it> wrote...
> > > > #define A(b) /* a
> > > > comment */ int b;
> > > >
> > > > A macro 'A' is defined, but not an int variable 'b'.
> > > >
> > > > Am I right?

> > v.Abazarov@attAbi.com ("Victor Bazarov") wrote
> > > The mention of newline characters in 2.1/1.3 has nothing to do with
> > > the comments.  Before the directive is executed, the code in your
> > > example will be transformed into
> > >
> > > #define A(b)   int b;
> > >
> > > (the comment is replaced with a single space char), or into
> > >
> > > #define A(b) int b;
> > >
> > > (the merging of the three spaces resulting from substituting the
> > > comment with one space into a single space is implementation-
> > > defined).

> On Wed, 11 Dec 2002, Allan W wrote:
> > I don't think that's right. Newline characters are retained. Furthermore
> > this is how it HAS to work, if __LINE__ is to have any meaning.
> >
> > So the expansion is
> >     #define A(b)
> >     int b;
> > unless I'm missing something.

ajo@andrew.cmu.edu ("Arthur J. O'Dwyer") wrote
> I think you're missing something:

And others seem to agree. Okay, I'm wrong, but...

> the fact that the behavior you're
> advocating is not only inconsistent with most (if not all) existing
> compilers, but also kind of dumb.  Replacing a comment with a space
> (as per the Standard quoted above) does *not* replace a comment with
> a newline.
>
> Presumably, as you point out, the sentence "Newlines are preserved."
> was added to the Standard precisely to preserve the usefulness of
> the __LINE__ macro.  However, the Standard does not say *where* the
> newline is to be preserved -- similarly to the well-known loophole
> in which the Standard constrains the implementation to translate one
> program per compilation unit, without specifying *which* program. :)
>
> IMO (and AFAICT in the opinion of most compiler-writers)
>
>   something;
>   #define A /* a
>   comment */ int b;
>   something_else;
>
> expands to
>
>   something;
>   #define A int b;
>
>   something_else;
>
> after the comment removal,

So the newline(s) moves to the end of whatever line the comments end on.
And this could easily include multiple newlines:

    something;
    #define A /* here    *
               * is a    *
               * comment */ int b; /* Here is *
                                    * another *
                                    * comment */
    something_else;

would expand to

    something;
    #define A int b;




    something_else;
with four blank lines, because the two comments had a total of 4
embedded newlines...?

> This seems quite logical behavior, and conforms
> to both the Standard and common practice.

Guess I hadn't thought about it that much, before.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Thu, 12 Dec 2002 19:50:23 +0000 (UTC), geert@cs.uu.nl ("Geert-Jan
Giezeman") wrote:

>My guess would be that is meant with the newline that is retained is the
>terminating newline of a // style comment.
>Such that
>
>#define A(b) // This macro is empty
>int b;
>
>is not equivalent to
>
>#define A(b) int b;

Actually I think it should be just clarified that the "terminating new
line" of a single-line comment is not part of it. Paragraph 2.7, which
defines both forms of comments, says:

   "The characters /* start a comment, which terminates with the
   characters */. [snip] The characters // start
   a comment, which terminates with the next new-line character."

Of course */ is part of a /**/-style comment, thus the similarity
between the two sentences "suggests" that the new-line is part of the
one-line comment as well. But that's of course not the intent and it
wouldn't be bad to have a correction.

Genny.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

allan_w@my-dejanews.com (Allan W) wrote in message news:<7f2735a5.0212121436.5d745f0a@posting.google.com>...
> > > > "Nicola Musatti" <nicola.musatti@objectway.it> wrote...
[...]
> > Presumably, as you point out, the sentence "Newlines are preserved."
> > was added to the Standard precisely to preserve the usefulness of
> > the __LINE__ macro.  However, the Standard does not say *where* the
> > newline is to be preserved -- similarly to the well-known loophole
> > in which the Standard constrains the implementation to translate one
> > program per compilation unit, without specifying *which* program. :)
> >
> > IMO (and AFAICT in the opinion of most compiler-writers)
> >
> >   something;
> >   #define A /* a
> >   comment */ int b;
> >   something_else;
> >
> > expands to
> >
> >   something;
> >   #define A int b;
> >
> >   something_else;
> >
> > after the comment removal,
>
> So the newline(s) moves to the end of whatever line the comments end on.

I don't agree with this interpretation. In my opinion we must
distinguish between the translation requirements, which must be and
are explicitly expressed in the standard, and the internal bookkeeping
that is needed to implement specific functions mandated by the
standard again.

The fact that __LINE__ is a macro does not make it necessary that
lines be counted during macro expansion. On the other hand, newlines
outside comments must be retained, because they serve as terminators
for preprocessor directives.

So, in my opinion the standard would be clearer if it was modified as
follows: in 2.1 [lex.phases], paragraph 3 should be changed to say:
"Each comment is replaced by one space character. *Remaining* newline
characters are retained." And in 2.7 [lex.comment], paragraph 1: "The
characters // start a comment, which terminates with the *last
character before the* next newline character."

Cheers,
Nicola Musatti

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 2002-12-12 02:28, "Paul Mensonides" <leavings@attbi.com> wrote:
[...]
> Line counting is supposed to happen in phase 1, which is before
> comments are removed and before macro expansion takes place:
>
> 16.4/2
>
> The _line number_ of the current source line is one greater than the
> number of new-line characters read or introduced in translation phase
> 1 (2.1) while processing the source file to the current token.
>
> Phase 1 only deals with character mappings such as universal character
> names and trigraphs.  This is even *before* backslash-newlines are
> removed (which is phase 2).  So a good test of whether the compiler is
> doing it the right way is this:
>
> 1:    #include <iostream>
> 2:
> 3:    #define TEST(a) a
> 4:
> 5:    int main() {
> 6:        std::cout << TEST( \
> 7:            __LINE__) << &std::endl;
> 8:        return 0;
> 9:    }
>
>
> The output *should* be 7, not 6, but many compilers get this wrong.

What about:

1:    #include <iostream>
2:
3:    #define TEST(a, b) a##b
4:
5:    int main() {
6:        std::cout << __LINE__ << TEST(__LI, \
7:            NE__) << __LINE__ << &std::endl;
8:        return 0;
9:    }

With gcc, this outputs 677. It's quite unclear what the output is
supposed to be according to the standard.

-- Niklas Matthies

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Niklas Matthies" <comp.std.c++_2002-12-15@nmhq.net> wrote in message
news:slrnavnpod.jb.comp.std.c++_2002-12-15@nmhq.net...
> On 2002-12-12 02:28, "Paul Mensonides" <leavings@attbi.com> wrote:

> What about:
>
> 1:    #include <iostream>
> 2:
> 3:    #define TEST(a, b) a##b
> 4:
> 5:    int main() {
> 6:        std::cout << __LINE__ << TEST(__LI, \
> 7:            NE__) << __LINE__ << &std::endl;
> 8:        return 0;
> 9:    }
>
> With gcc, this outputs 677. It's quite unclear what the output is
> supposed to be according to the standard.

Yeah, this is a good one!  My guess would be the broken __LINE__ should
expand to 7 because it only becomes __LINE__ inside the invocation of TEST
which cannot be invoked without preceding to the terminating parenthesis.
It is unclear, though, whether a line-split macro invocation (like TEST
above) should expand onto the start line or the finish line.  In this
particular case, the backslash is unnecessary.  The same type of problem
exists here:

1:    TEST(
2:        __LI,
3:        NE__
4:    )

Does TEST expand on line 1 or on line 4?  My guess would be line 4, because
of this:

1:    TEST
2:    (
3:        __LI,
4:        NE__
5:    )

If the next token following TEST is _not_ an open parenthesis, TEST would
not expand at all.  Therefore, I think it is not fully "invoked" until the
terminating parenthesis of the macro invocation since the expansion depends
on the argument list.  I appears to that GCC is doing what appears to be the
"right thing," IMHO.

Not that it really matters to much.... ;)

Paul Mensonides

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> "Nicola Musatti" <nicola.musatti@objectway.it> wrote...
> > Hallo.
> > ...where
> > it is said that "Each comment is replaced by one space character.
> > Newline
> > characters are retained." (2.1/1.3) I assume it to mean that first each
> > comment is replaced by a single char, then the remaining newlines are
> > retained. In other words in the following example:
> >
> > #define A(b) /* a
> > comment */ int b;
> >
> > A macro 'A' is defined, but not an int variable 'b'.
> >
> > Am I right?

v.Abazarov@attAbi.com ("Victor Bazarov") wrote
> The mention of newline characters in 2.1/1.3 has nothing to do with
> the comments.  Before the directive is executed, the code in your
> example will be transformed into
>
> #define A(b)   int b;
>
> (the comment is replaced with a single space char), or into
>
> #define A(b) int b;
>
> (the merging of the three spaces resulting from substituting the
> comment with one space into a single space is implementation-
> defined).

I don't think that's right. Newline characters are retained. Furthermore
this is how it HAS to work, if __LINE__ is to have any meaning.

So the expansion is
    #define A(b)
    int b;
unless I'm missing something.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Allan W" <allan_w@my-dejanews.com> wrote...
> > "Nicola Musatti" <nicola.musatti@objectway.it> wrote...
> > > Hallo.
> > > ...where
> > > it is said that "Each comment is replaced by one space character.
> > > Newline
> > > characters are retained." (2.1/1.3) I assume it to mean that first
each
> > > comment is replaced by a single char, then the remaining newlines are
> > > retained. In other words in the following example:
> > >
> > > #define A(b) /* a
> > > comment */ int b;
> > >
> > > A macro 'A' is defined, but not an int variable 'b'.
> > >
> > > Am I right?
>
> v.Abazarov@attAbi.com ("Victor Bazarov") wrote
> > The mention of newline characters in 2.1/1.3 has nothing to do with
> > the comments.  Before the directive is executed, the code in your
> > example will be transformed into
> >
> > #define A(b)   int b;
> >
> > (the comment is replaced with a single space char), or into
> >
> > #define A(b) int b;
> >
> > (the merging of the three spaces resulting from substituting the
> > comment with one space into a single space is implementation-
> > defined).
>
> I don't think that's right. Newline characters are retained. Furthermore
> this is how it HAS to work, if __LINE__ is to have any meaning.
>
> So the expansion is
>     #define A(b)
>     int b;
> unless I'm missing something.


If new-line characters inside comments are retained (as you
insist), then the two statements contradict each other.
A multiline comment that opens with /* and closes with */ umpteen
lines later cannot be replaced with _one_ space character while
retaining new-line characters at the _same__time_.

Now, what does this have to do with __LINE__ I am not sure.  The
implementation is free to keep track of new-line characters in the
source file whether they fall into a comment or not, it doesn't
mean the lines have to be counted after removal of comments.

Victor
--
Please remove capital A's from my address when replying by mail


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Wed, 11 Dec 2002, Allan W wrote:
>
> > "Nicola Musatti" <nicola.musatti@objectway.it> wrote...
> > > Hallo.
> > > ...where
> > > it is said that "Each comment is replaced by one space character.
> > > Newline
> > > characters are retained." (2.1/1.3) I assume it to mean that first each
> > > comment is replaced by a single char, then the remaining newlines are
> > > retained. In other words in the following example:
> > >
> > > #define A(b) /* a
> > > comment */ int b;
> > >
> > > A macro 'A' is defined, but not an int variable 'b'.
> > >
> > > Am I right?
>
> v.Abazarov@attAbi.com ("Victor Bazarov") wrote
> > The mention of newline characters in 2.1/1.3 has nothing to do with
> > the comments.  Before the directive is executed, the code in your
> > example will be transformed into
> >
> > #define A(b)   int b;
> >
> > (the comment is replaced with a single space char), or into
> >
> > #define A(b) int b;
> >
> > (the merging of the three spaces resulting from substituting the
> > comment with one space into a single space is implementation-
> > defined).
>
> I don't think that's right. Newline characters are retained. Furthermore
> this is how it HAS to work, if __LINE__ is to have any meaning.
>
> So the expansion is
>     #define A(b)
>     int b;
> unless I'm missing something.

I think you're missing something: the fact that the behavior you're
advocating is not only inconsistent with most (if not all) existing
compilers, but also kind of dumb.  Replacing a comment with a space
(as per the Standard quoted above) does *not* replace a comment with
a newline.

Presumably, as you point out, the sentence "Newlines are preserved."
was added to the Standard precisely to preserve the usefulness of
the __LINE__ macro.  However, the Standard does not say *where* the
newline is to be preserved -- similarly to the well-known loophole
in which the Standard constrains the implementation to translate one
program per compilation unit, without specifying *which* program. :)

IMO (and AFAICT in the opinion of most compiler-writers)

  something;
  #define A /* a
  comment */ int b;
  something_else;

expands to

  something;
  #define A int b;

  something_else;

after the comment removal, and

  something;


  something_else;

after #define pre-processing (for those compilers I tested with an
external preprocessor).  This seems quite logical behavior, and conforms
to both the Standard and common practice.

-Arthur


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Victor Bazarov"" <v.Abazarov@attAbi.com> wrote in message

[snip]

> Now, what does this have to do with __LINE__ I am not sure.  The
> implementation is free to keep track of new-line characters in the
> source file whether they fall into a comment or not, it doesn't
> mean the lines have to be counted after removal of comments.

Line counting is supposed to happen in phase 1, which is before comments are
removed and before macro expansion takes place:

16.4/2

The _line number_ of the current source line is one greater than the number
of new-line characters read or introduced in translation phase 1 (2.1) while
processing the source file to the current token.

Phase 1 only deals with character mappings such as universal character names
and trigraphs.  This is even *before* backslash-newlines are removed (which
is phase 2).  So a good test of whether the compiler is doing it the right
way is this:

1:    #include <iostream>
2:
3:    #define TEST(a) a
4:
5:    int main() {
6:        std::cout << TEST( \
7:            __LINE__) << &std::endl;
8:        return 0;
9:    }


The output *should* be 7, not 6, but many compilers get this wrong.

Paul Mensonides



---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Nicola Musatti"" <nicola.musatti@objectway.it> wrote in message
news:daadbd9428312ec9894d60148c1e3675_2394@mygate.mailgate.org...
> Hallo.
> I'd beg someone more experienced than me to confirm my interpretation of
> paragraph 2.1 of the Standard. Specifically, I'm assuming that not only
> each phase of translation is meant to be performed as if in strict
> sequential order, but also every step in each phase. For instance where
> it is said that "Each comment is replaced by one space character.
> Newline
> characters are retained." (2.1/1.3) I assume it to mean that first each
> comment is replaced by a single char, then the remaining newlines are
> retained. In other words in the following example:
>
> #define A(b) /* a
> comment */ int b;
>
> A macro 'A' is defined, but not an int variable 'b'.
>
> Am I right?

My guess would be that is meant with the newline that is retained is the
terminating newline of a // style comment.
Such that

#define A(b) // This macro is empty
int b;

is not equivalent to

#define A(b) int b;



---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hallo.
I'd beg someone more experienced than me to confirm my interpretation of
paragraph 2.1 of the Standard. Specifically, I'm assuming that not only
each phase of translation is meant to be performed as if in strict
sequential order, but also every step in each phase. For instance where
it is said that "Each comment is replaced by one space character.
Newline
characters are retained." (2.1/1.3) I assume it to mean that first each
comment is replaced by a single char, then the remaining newlines are
retained. In other words in the following example:

#define A(b) /* a
comment */ int b;

A macro 'A' is defined, but not an int variable 'b'.

Am I right?

Cheers,
Nicola Musatti


--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Nicola Musatti" <nicola.musatti@objectway.it> wrote...
> Hallo.
> I'd beg someone more experienced than me to confirm my interpretation of
> paragraph 2.1 of the Standard. Specifically, I'm assuming that not only
> each phase of translation is meant to be performed as if in strict
> sequential order, but also every step in each phase. For instance where
> it is said that "Each comment is replaced by one space character.
> Newline
> characters are retained." (2.1/1.3) I assume it to mean that first each
> comment is replaced by a single char, then the remaining newlines are
> retained. In other words in the following example:
>
> #define A(b) /* a
> comment */ int b;
>
> A macro 'A' is defined, but not an int variable 'b'.
>
> Am I right?

The mention of newline characters in 2.1/1.3 has nothing to do with
the comments.  Before the directive is executed, the code in your
example will be transformed into

#define A(b)   int b;

(the comment is replaced with a single space char), or into

#define A(b) int b;

(the merging of the three spaces resulting from substituting the
comment with one space into a single space is implementation-
defined).

Victor
--
Please remove capital A's from my address when replying by mail


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Wed, 11 Dec 2002 03:38:50 +0000 (UTC), nicola.musatti@objectway.it ("Nicola Musatti") wrote:

>Hallo.
>I'd beg someone more experienced than me to confirm my interpretation of
>paragraph 2.1 of the Standard. Specifically, I'm assuming that not only
>each phase of translation is meant to be performed as if in strict
>sequential order, but also every step in each phase. For instance where
>it is said that "Each comment is replaced by one space character.
>Newline
>characters are retained." (2.1/1.3) I assume it to mean that first each
>comment is replaced by a single char, then the remaining newlines are
>retained. In other words in the following example:
>
>#define A(b) /* a
>comment */ int b;
>
>A macro 'A' is defined, but not an int variable 'b'.
>
>Am I right?

ROTFL. :-)

Seriously, I don't think the above interpretation is correct wrt.
the actual text.  IMHO the text implies that all newlines are
retained, including those in comments, because "Newline characters
are retained" does absolutely not make sense as a separate step.  On
the other hand, I think the interpretation is correct wrt. the
intention, and wrt. current compilers  --  e.g. g++ 3.2 and MSVC 7.0
do it this way (the two lines are merged, no int variable 'b').

Isn't that a FAQ, by the way?  Uh, no, it doesn't seem to be, but
[http://www.parashift.com/c++-faq-lite/coding-standards.html#faq-27.13]
is at least relevant... ;-)

It might be listed as a defect or not.

If it isn't, then IMHO it certainly should be listed as a defect.

Cheers,

- Alf

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]