Single line comment continuation

问题:

From the C++ standard (going back to at least C++98) § 2.2, note 2 states:

Each instance of a backslash character (\) immediately followed by a new-line character is deleted, splicing physical source lines to form logical source lines. Only the last backslash on any physical source line shall be eligible for being part of such a splice. Except for splices reverted in a raw string literal, if a splice results in a character sequence that matches the syntax of a universal-character-name, the behavior is undefined. A source file that is not empty and that does not end in a new-line character, or that ends in a new-line character immediately preceded by a backslash character before any such splicing takes place, shall be processed as if an additional new-line character were appended to the file.

And, section § 2.7 states:

The characters /* start a comment, which terminates with the characters */. These comments do not nest. The characters // start a comment, which terminates with the next new-line character. If there is a form-feed or a vertical-tab character in such a comment, only white-space characters shall appear between it and the new-line that terminates the comment; no diagnostic is required. [Note: The comment characters //, /*, and */ have no special meaning within a // comment and are treated just like other characters. Similarly, the comment characters // and /* have no special meaning within a /* comment. ]

I would take these two together to mean that the following:

// My comment \
is valid

// My comment \ still valid \
is valid

are legal in C++98. In GCC 4.9.2, these both compile without any diagnostic messages. In MSVC 2013, these both produce the following:

warning C4010: single-line comment contains line-continuation character

If you have warnings as errors enabled (which, I do), this causes the program to not compile successfully (without warnings-as-errors, it works just fine). Is there something in the standard that disallows single-line comment continuations, or is this a case of MSVC non-compliance with the standard?

回答1:

I'd say it's MS being sensitive to the fact that if you do something like:

#define macro() \
    some stuff \
    // Intended as comment \
    more stuff

then you get VERY interesting errors when you use macro() in the code.

Or other simply accidentally typing a comment like this:

// The files for foo-project are in c:\projects\foo\
int blah;

(Strange errors for "undefined variable blah" occurs)

I would NEVER use line continuation in a single-line comment, but if you have some good reason to, just turn THAT warning off in MSVC.

Also as Mike says: Warnings are not even covered by the standard - it only says what needs to be an error. If you enable "warnings are errors", you will have to either be selective about what warnings you enable, or accept that some constructs that are technically valid (but dubious) will be unacceptable in the build, because the compiler maker has decided to warn about it. Try writing if (c = getchar()) in gcc or clang and see how far you get with much -Werror and warnings on "high". Yet it is perfectly valid according to the standard.

回答2:

It's not a question of compliance. You've specifically asked the compiler to treat a valid construct as an error, so that's what it does.

GCC will give the same warning (or error, if requested) if you specify -Wcomment or -Wall.