The name of the header guard lacks a prefix with the name of the library or namespace. The name was not changed after changing the name of the file, class or namespace. The name used with ifndef does not match the one used with define.
Using pragma once will delegate the task, of detecting subsequent include statements for the same file, to the compiler. It can do this efficiently and safely. As a user, there is no room for mistakes. Just place the directive in the first line of every header file. There is no unique name you have to write correctly and no endif which must exist at the end of the file. Also, if you change the name of the file or class, no changes are required. All pragma statements are meant to be compiler-specific instructions which are per definition not portable.
Therefore using pragma once is not guaranteed to be implemented by a compiler and also, there is no standardised way how duplicate includes are detected. Detecting duplicate includes is not always as simple as it seems: If a project uses symlinks to include libraries, the same header file may be accessed using two different absolute paths.
Also, compiling has not necessarily be done on the same computer; it can be split up to many processes and executed on different servers on the network. For these reasons, the first accepted proposal for a pragma once replacement was not made until with the number PR0.
It suggests the new preprocessor directives once and forget as a qualified replacement. So, do not expect to have modules or the once statement until The pragma once statement is supported by almost all compiler suites, even most for embedded development.
You can safely use it and expect it will work with any compiler. A Wikipedia page will give you a list of compiler and their support of the statement. I recommend using pragma once instead of old macro-based header guards.
It will reduce the number of preprocessor macros and prevent potential and hard to find compilation problems. You should also replace existing macro-based header guards with this statement if you do maintenance work on existing code. The statement is supported by all relevant compiler suites in a very efficient and safe way. While there may be rare problem cases, in distributed compiling environments, this will affect just a few users who are well aware of this.
I hope this article gave you some motivation to get rid of your old macro-based header guards. If you are not sure if pragma once will work for your project, replace the old guards using a script and try to compile it. If you have questions, miss some information or have any feedback, feel free to add a comment below. This site uses Akismet to reduce spam.
It requires less typing, it's less distracting, and it can't cause symbol collisions. Symbol collisions are errors caused when different header files use the same preprocessor symbol as the guard value. There's no advantage to use of both the include guard idiom and pragma once in the same file. The compiler recognizes the include guard idiom, and implements the multiple-include optimization the same way as the pragma once directive if no non-comment code or preprocessor directive comes before or after the standard form of the idiom:.
We recommend the include guard idiom when code must be portable to compilers that don't implement the pragma once directive, to maintain consistency with existing code, or when the multiple-include optimization is impossible. It can occur in complex projects when file system aliasing or aliased include paths prevent the compiler from identifying identical include files by canonical path. Function declaration. Lambda function declaration.
Fundamental types. Function types. Compound types. Storage duration specifiers. Default initialization. Value initialization. Zero initialization. Copy initialization. Direct initialization. Aggregate initialization. Constant initialization. Reference initialization. Value categories. Order of evaluation. Operator precedence. Alternative representations. However, this has been implemented in major compilers, such that this makes no difference nowadays. Perhaps you have some special compiler for your embedded system.
That one might be unable to use pragma once. In general I prefer pragma once because when you duplicate a header file in order to do incremental refactoring by duplication or extending a class, you cannot forget to change the name of the include guard macro. Therefore I do not know of any hard problem you have with pragma once , except for certain compilers.
In using pragma once you are giving up portability.
0コメント