Are tokens after #endif legal?

Question

I currently do the following and the compiler (MSVC2008 / as well as 2010) doesn't complain about it but I'm not sure if it's a bad idea or not:

#ifndef FOO_H_
#define FOO_H_

// note, FOO_H_ is not a comment:
#endif FOO_H_

I used to always write it as #endif // FOO_H_ but I caught myself not doing that today and thought it was strange because apparently I've not done the comment method for a while.

Is this bad practice that I should go back through all of my headers and fix (it's a cross-platform application) or is it okay to leave it the way it is?

Answer 1

It is not ok, it is not valid, AFAIK. Many compilers ignore the extra text after the #endif though and often they warn about it. You should add the // to make it a comment.

Answer 2

Strictly speaking (according to the grammar in the standard) no tokens are allowed following the #endif directive on the same line (comments are OK since they get removed at an earlier phase of translation than the preprocessing directives - phase 3 vs. 4).

However, MSVC seems to allow it - I wouldn't go on a quest to fix these (since they aren't causing a problem), but would probably make a mental note to fix them as you modify the headers that have them.

Of course, if your other supported compilers issue diagnostics about them it's probably more urgent to fix them.

Answer 3

With what everyone else posted, I figured I might help you with actually correcting the issue. (assuming it is in many files.)

You can use the Find and Replace feature in visual studio to correct all of the problematic lines at once. Just set Find What: to "\#endif {[a-zA-Z\.\_]+}$" and Replace With: to "#endif //\1" (and make sure you have Use: [Regular Expressions] checked under find options.)

And do that on the whole solution and you should be good to go.

(Please back up your project first, I have tested this and it seems to be working as intended but Use this at your own risk.)

Answer 4

Why your compiler should warn you about it.

Say your header file is like this:

#ifndef X
#define X
// STUFF
// The next line does not contain an EOL marker (can happen)
#endif

Now you include this from source

#include "plop.h"
class X
{
}

When the compiler includes the file technically the expanded source should look like this

#define X
// STUFF
// The next line does not contain an EOL marker (can happen)
#endif class X
{
}

Most modern compiler take into account his could happen and stick an extra EOL token on included files to prevent this from happening (technically not allowed but I can't think of a situation where it would cause a problem).

The problem is that some older compilers don't provide this extra token (more standards compliant) but as a result you can potentially end up compiling the above code (as a result they tend to warn you about two things 1) missing EOL in source files and 2) things after the #endif