Quote:Original post by petewood I think compiler writers have worked out that #ifndef and #pragma once should have the same effect and will make them equally efficient.
Yes and no. Yes they have the same effect, but #pragma once can tell the compiler to abandon what its doing instead of having to parse through the whole file to reach the #endif. But that'll make all of 1ms difference...
I think you're missing the point. The compiler writer can say, after seeing pragma once, 'this file should only be parsed once, next time I see it included I won't even open it.' The same decision can be made after realising that you have an ifndef/endif pair round the whole file.
#pragma once Big advantage: in that the compiler flags this file as to be OPEN once and READ once for a compilation of the source file. This saves alot of opening and closing the included file. Big disadvantage: is it only works on a few compilers.
I have always use #ifndef #endif include guards. Advantage: it works on all C/C++ compilers or more correctly the preprocessor. Disadvantage: you still OPEN and have to READ the include file to check for the include guard.
I found on web site I don't remember were to do some added inclusion guards in the file your compiling.
Quote:Original post by Lord Bart Advantage: it works on all C/C++ compilers or more correctly the preprocessor. Disadvantage: you still OPEN and have to READ the include file to check for the include guard.
If you know that it's a waste of time opening the file and reading it more than once, the compiler writer will also know it's a waste of time. They won't open and read it more than once.
Quote:Original post by Lord Bart Advantage: it works on all C/C++ compilers or more correctly the preprocessor. Disadvantage: you still OPEN and have to READ the include file to check for the include guard.
If you know that it's a waste of time opening the file and reading it more than once, the compiler writer will also know it's a waste of time. They won't open and read it more than once.
Agreed.
Quote:Original post by Lord Bart #ifndef NAME_OF_INCLUDED_DEFINE #include "name_of_inlcude_file.h" #endif
I can only see the usefullness of this three lined code repetition if your statement on re-parsing is true which I find hard to believe except for very old preprocessors.
Again I wish to draw the attention to the usefullness of converting debugged code into libraries.
Here's a better tip: stop using a leading underscore for inclusion guard identifiers. 90% of the example C++ header files I see posted have this and these types of identifiers are reserved for the compiler only.
You cannot as a compiler writer know weather a file should only be open and read once. you need help from programer ie #pragma once or a directive like cmd line arg to only include file once.
What if the included file needs to be included more then once. Don't know why off the top of my head, but it just might. So what do you do. Each #include open and parse the file.
Next leading underscore _ can still be use just need to be careful.
Form what I found out is. Leading 2 underscore are reserved for compiler implementation. Never use. Single leading followed by a digit or upper case letter is reversed for system use. ie include files provide by the OS. Single underscore followed by lower case letter is allowed in user name space but not global (ie std).
I have had no problem with leading _ because I don't name my files after OS provided includes.
That's not to say its totaly right to do, it is just something I do. My include guards have leading and ending _. Just so then aren't confused with reg. defines.
I also like how ifndef and define are the same length. I type the ifndef line, then just the #define part, cursor up, shift end, copy, cursor down, paste.
This won't get confused with any regular name, and doesn't start with an underscore.
