Not sure where to put this, but...
If you create a multi line comment with '// \' then the next line is correctly comment colored, but if you put a space after '// \ ' then the next line is no longer comment colored, but the compiler still ignores the next line. The comment color should not change if after the \ is only whitespace from what I understand of the compiler.
I see the same behavior with 1.8.19.
// is just for a single line C++ style comment.
I think, it does not understand the backslash to combine lines (it is just for code lines, not comments, the backslash is part of 'ignored' comment and not "seen", C/C++ compilers do not decode commented lines, so the backslash is not doing anything, just part of the comment, otherwise a backslash n would act in a comment - it does not! It is just a regular character inside the comment without any meaning).
You have to comment each line with //.
Or, you wrap a C-comment around all:
/*
//C++-comment
* other comment
*/
I'm actually surprised to learn it works with trailing space
The \ in a line like this:
// hello world \<line feed>
Is escaping the line feed character. So the semantics are that it is preventing the character from having its normal function, just as is the case with something like Serial.print("foo \"bar\" baz").
But in a line like this:
// hello world \<space><line feed>
the \ is escaping the space character, not the line feed character.
I see that you are correct that GCC allows trailing whitespace after the line continuation:
Continued lines are merged into one long line.
A continued line is a line which ends with a backslash, . The backslash is removed and the following line is joined with the current one. No space is inserted, so you may split a line anywhere, even in the middle of a word. (It is generally more readable to split lines only at white space.)
The trailing backslash on a continued line is commonly referred to as a backslash-newline.
If there is white space between a backslash and the end of a line, that is still a continued line. However, as this is usually the result of an editing mistake, and many compilers will not accept it as a continued line, GCC will warn you about it.
But that statement is specific to GCC. The C++ specification is not so lenient:
https://timsong-cpp.github.io/cppwp/n3337/lex.phases#1.2
Each instance of a backslash character (
\) immediately followed by a new-line character is deleted, splicing physical source lines to form logical source lines.
Note it says "immediately".
Even though most Arduino boards platforms use GCC, the C++ syntax highlighter used by Arduino IDE 2.x is for C++ code in general, not GCC-specific. The syntax highlighting system does not know anything about the non-standard conventions of whatever compiler might be in the selected board's toolchain, so it makes sense that it would follow the C++ specification even where the compiler does not.
In practice, I don't think the inconsistency is really of concern because it is best practices to always remove trailing whitespace from your code and the Arduino IDE's Auto Format feature even does that for you.
I hadn't thought to use autoformat, I just wrote my code and then spent a couple hours tracking down (and then posting to the forum) to find out it was a trailing space that caused the issue. I had originally placed the trailing space because I wanted the comment to end in \, and putting in the space made the IDE show the next line uncommented. It was my poor assumption, but I assumed that because the next line was not comment colored, it would compile that way.
Again, backslash is usable in active code line, e.g. also strings.
But not in comments: in a comment the backslash becomes a regular character and is ignored (does not do anymore the multi-line concatination).
Don't use backslash in comments to assume it does this ... just as any other character and taken as ignored.
OK, so it seems you won't trust the word of the C++11 specification and the GCC documentation.
Then let's try an experiment to test your hypothesis. I'll avoid using Arduino sketch conventions in the program because I know you don't use the Arduino framework:
// hello world \
#error
int main() {
return 0;
}
If your hypothesis that line continuation is not possible in comments is correct, we would expect the compilation of this program to fail due to the #error directive.
If the C++ specification and GCC documentation is correct, we would expect the compilation of this program to succeed because the #error is only part of the comment.
So what result did you find when you ran the experiment?
Something to note: since continued lines in comments are sometimes unintended, for example:
// I "balanced" this comment to make it pretty \\
there is a compiler warning for continued lines in comments:
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wcomments
So yes, if your compilation command uses -Werror then the compilation will fail. But that type of a failure does not in any way back the hypothesis that line continuation is not possible in comments. In fact, it does just the opposite since if it was not possible there would be no need for the compiler developers to implement a warning about it.
Yes, I do not trust the C++ spec.
But you are right!
I tried right now, even with C code, with GNU compiler, in STM32 CubeIDE - which seems to work (at least in the GUI).
But when GUI displays correctly - I would not assume the compiler will see it also correctly in the same way: bear in mind: the syntax highlighting in GUI does not mean how the compiler will see it.
GUI code highlighting is independent of how compiler is using code.
//comment \
hallo
hi
Never mind: I would not use such "special tricks" if not needed, just to avoid such issues (esp. on different compilers).
My "coding rules" say: do not use backslash in comments, instead comment every single line via // or use C-style comments via /* . But do not trust special features: reusing code on a different compiler (and version) can fail, later on different IDEs, GUIs, compilers.
And GUI code highlighting is not the same as compiler will use the code (how often I have seen that GUI does not follow my macros properly, shows me disabled code even macros are set, but effective during compile time).
I think - it is a feature of the GUI but it does not mean your compiler will take it the same way.
Keep GUI display and compiler syntax differently (be conservative).
The GUI syntax highlighting is NOT related to the compiler version you use.
I think, you can configure which style for syntax highlighting the GUI should use. But it does not mean your compiler also accepts the same syntax "highlighted" as "correct" in GUI. GUI and compiler can differ in "accepted coding style".
GUI and compiler are two different animals.
I agree 100%. I would never do this. I only knew it was possible because I have helped some forum members who ran into mysterious code bugs after they "prettied up" their comments like I showed in my previous reply. We have the /**/ comment syntax for that purpose. I think it is good they added that -Wcomments warning.
I just wanted to bring this to light and I am glad it seems to have driven a decent discussion even if I think it missed my original point.
My original point was for new developers, the default installation in windows is incorrect between the syntax highlighting and the compiled version. I know difference exist in a variety of formats, but if a new user installs the software and changes nothing then gets compiled code that doesn't seem to work the way the IDE says, that can lead to people abandoning their efforts as they assume they just don't understand the system or are incapable of figuring it out. I would hate for someone to make that assumption due to an oddity between the two.
In this case, I don't think it would likely happen, because how often is a \ placed at the end of a comment (especially for newer users).
I totally agree:
you should not "learn" coding via "syntax highlighting". This feature is independent of the compiler and there is not a correlation between both).
Like coding with VIM: you can load "syntax-coloring" but it does not mean it will be accepted by the compiler at the end.
There is another "uncertain" issue:
If you create a string, can you do this?
char * myStr = "str1" "str2" "str3";
It depends heavily if your compiler would accept this syntax (and combines all strings into one).
It can look differently in IDE via syntax highlighting.
Similar when you do:
char *s = "\n";
char *s = "\\n";
I would guess, not a big difference (even not any) in syntax highlighting in IDE, but a big difference for the compiler (what it will see and do).
The compiler must support that syntax as it's part of the standard (they are called "adjacent string literal tokens", at least in the C standards). Whether or how a syntax highlighter supports it depends on the specific syntax highlighter (it's not as important for a syntax highlighter as it is for a compiler to support all of a language's syntax, even the more obscure syntax).
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.