To preventing multiple inclusion of header files, in a project, what would you recommend to do?
Using the include guard macro, or the #pragma once directive?
Are they both the same, or is there any reason whereby we should preferably use the one rather than the other?
Look here (http://stackoverflow.com/questions/1143936/pragma-once-vs-include-guards).
Not exactly same.
#pragma once prevent opening file with same name, so no parsing after this.
For other compilers use both.
Simple test, uncomment lines to see what happens:
test_pragma_once.c
#include "test_pragma_once.h"
#include "test/test_pragma_once.h"
#include "test_pragma_once.h"
#include "test\test_pragma_once.h"
int main(void) {return 0;}
test_pragma_once.h#pragma once
#pragma message("1. test_pragma_once.h")
#ifndef _TEST_PRAGMA_ONCE_H
#define _TEST_PRAGMA_ONCE_H
#pragma once // this prevent include in same name in same folder
#pragma message("test_pragma_once.h")
#endif // _TEST_PRAGMA_ONCE_H
test\test_pragma_once.h#pragma once
#pragma message("2. test/test_pragma_once.h")
#ifndef _TEST_PRAGMA_ONCE_H // this prevent include in same name in different folder
#define _TEST_PRAGMA_ONCE_H
#pragma once
#pragma message("test/test_pragma_once.h")
#endif // _TEST_PRAGMA_ONCE_H
Building test_pragma_once.obj.
1. test_pragma_once.h
test_pragma_once.h
2. test/test_pragma_once.h
Done.
Thanks Timo,
Reading your post and your link, it seems that there is not a simple answer.
Now I am a bit confused. I might conclude that the best choice for all my PellesC projects will be using the #pragma once directive making sure that any project will never accept files with the same name in different folder.
Could it be a good choice?
The common practice is to use the standard #ifdef/#define and inside use the #pragma once checking if supported.
For PellesC could be like this:
#ifndef _MYHEADER_H
#define _MYHEADER_H
/* If using a compiler version that supports it use pragma once */
#if __POCC__ >= 500
#pragma once
#endif
//My defines here
....
#endif //_MYHEADER_H
#pragma once
Does not seem to make any difference in speed.
John
Quote from: frankie on June 02, 2016, 04:24:01 PM
#ifndef _MYHEADER_H
#define _MYHEADER_H
/* If using a compiler version that supports it use pragma once */
#if __POCC__ >= 500
#pragma once
#endif
//My defines here
....
#endif //_MYHEADER_H
Why the
#pragma once inside the
#ifndef and not outer?
Quote from: PaoloC13 on June 02, 2016, 05:53:51 PM
Why the #pragma once inside the #ifndef and not outer?
I think, as often happen in coding, at introduction of pragma once this was requested to avoid to apply it more than once, then it become almost a standard.
Quote from: PaoloC13 on May 31, 2016, 01:49:15 AM
To preventing multiple inclusion of header files, in a project, what would you recommend to do?
Using the include guard macro, or the #pragma once directive?
Are they both the same, or is there any reason whereby we should preferably use the one rather than the other?
Best to use the ...
#ifndef HEADER_H
#define HEADER_H
// your stuff here
#endif
... format since only a relatively few compilers support the prgama.
Quote from: Scripter on June 03, 2016, 09:04:23 PM
Best to use the ...
#ifndef HEADER_H
#define HEADER_H
// your stuff here
#endif
... format since only a relatively few compilers support the prgama.
as evidenced by TimoVJL, the two options are not exactly the same thing.
Moreover, frankie has used:
#if __POCC__ >= 500
#pragma once
#endif
which reduces the code to the usual
#ifndef macro scheme, if the compiler does not support the
#pragma once directive.
Mostly, I wonder what is the most appropriate choice using specifically the PellesC compiler, which supports it.
If you compile only with a PellesC compiler, which version is >=5.00, simply use #pragma once.
Quote from: frankie on June 06, 2016, 05:20:49 PM
If you compile only with a PellesC compiler, which version is >=5.00, simply use #pragma once.
Ok frankie, I think I'll do it this way, maybe being careful not to use the same file into other parts of a project.
The directive is also supported by almost all modern compilers.