Jump to content
  • Advertisement
Sign in to follow this  
wendigo23

#ifndef/#define or #pragma once?

This topic is 5442 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Quote:
Original post by Evil Steve
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.

Share this post


Link to post
Share on other sites
Advertisement
Hello All,

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

In your source file.

#ifndef NAME_OF_INCLUDED_DEFINE
#include "name_of_inlcude_file.h"
#endif

If this is done each time you include a file then you can avoid OPEN and READ of the include file, once the inclusion guard has been defined.

I have started to do this on the project I work on.
But only when I changing a file at the time.

Also work well when the guard is base on the file name to be included.
ie. my_time.h has include guard _MY_TIME_H_

Lord Bart

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by petewood
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

But you don't have to do what I do. :)

Lord Bart

Share this post


Link to post
Share on other sites
Guest Anonymous Poster


#include "app.h" //application constants and includes such as stl

#ifndef CMyClass_h
#define CMyClass_h

class CMyClass{
private:
public:
};

#endif

Share this post


Link to post
Share on other sites
Personally, my preference is:

#ifndef INC_FILENAME_H_
#define INC_FILENAME_H_

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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!