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?

Thithia

I get a warning with GCC (extra tokens), so I wouldn't suggest that. – Marcie

I was trying to ask if it's an acceptable thing to do as far as the standard is concerned - or if it was implemtnation specific or something else - I'm not really sure. Maybe the best wording would have been "is this proper?" - either way I don't want warnings when the app gets compiled on other OS's so I'll remove them - thanks. – Thithia

@Joe: Sorry, I read the question wrong. – Sundaysundberg

@GMan: No problems at all^^ - thanks for correcting the title too :D – Thithia

@Joe: You should properly @attribute comment answers, otherwise they won't show up in the responses list of the person you're responding to. – Heirship

@sbi: Oh, I wasn't aware that did anything, maybe I should register an account on here sometime and I'll learn some stuff. Thanks for pointing it out though! – Thithia

@Joe: You have an account, otherwise you couldn't post. At the top right of every page, there's a link to the FAQ. Reading it will help you finding your ways around here. – Heirship

Answer 1

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.

Pervert

My main concern was that when the application is ported to other OS's it might cause something if this behavior isn't allowed, and since it isn't I'll just fix it. Shouldn't take all that long really anyway. Thanks though! – Thithia

Answer 2

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.

Indeclinable

Okay, I'm not looking to get any warnings on it so I'll go back and fix it, thanks! – Thithia

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.)

Concavoconvex

Oh now that is awesome, I had no idea you could use regexp's in the find and replace box. I'm not very good with them though, it's telling me "Syntax error in pattern" and highlighting "#endif {[a-zA-Z._]+}$" - am I doing something incorrect? -- edit: Oops, can't use the # in there or it breaks it. It's working now, thank you very much! – Thithia

there should be slashes () in front of the #, . and _. Not sure why they got removed? (like this: \#endif {[a-zA-Z\._]+}$ ) – Concavoconvex

@Thithia It removed the one before the _ there to. Not sure why. Just add it back in and you will be good. – Concavoconvex

Ah! Well it appears to have worked just fine anyway, but I'll use the backup and use the proper one just to be sure. Thank you very much though - I'll have to keep that trick handy in case I ever have mess up again :D – Thithia

I took the liberty to edit your post so that the backslashes are visible. +1 from me for posting an actual solution! @Joe: If you have to backup your project, that indicates you're not using an SCM. That's bad and will hurt you in the long run. – Heirship

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

Clop