According to Coding Standards, developers of LLVM project must use header guards. I think it is a kind of artificial and outdated restriction, since ALL of the compilers which can build the LLVM support #pragma once. Pragma once - Portability
I propose to allow using #pragma once in new code and make it preferable way (and maybe gracefully replace header guards in existing headers). In my opinion, this little change in the Policy can lower a bit the “code noise” (since the code is made to be read by people).
2 Likes
Using #pragma once seems unnecessarily hostile to other compilers we, or someone else, might want to support in future. I don’t see much tangible benefit for it beyond removing 2 lines per header file.
Actually I can not imagine the compiler, which has c++17 support and does not recognise #pragma once statement.
Yes, classic guards are just two more lines, but there are some disadvantages of this approach.
- You have to make unique name for guard. Now the path of the files are used, which can be annoying if you move some headers.
- Sometimes it is difficult to figure out which blocks of code are active in macro-intensive headers.
- It is not as semantically dedicated as
#pragma once.
- It is just unnecessary noise and verboseness.
2 Likes
C++17 is standard, #pragma once is non-standard. So… I can easily imagine such a compiler.
3 Likes
Wow! According to this table, it seems that C++17 standard is not standard. (*irony*)
Seriously, I do not see any reason to strongly deny #pragma once. I do not say that everyone MUST use it, I just propose to make it acceptable (at least).
Kindly take your snark elsewhere. Standard in this context does not mean prevalent.
2 Likes
I don’t really see a reason why we should use it. It’s not exactly hard to write headers guards, #pragma once is non-standard and has slightly different behaviour on different compilers (one of the reasons it’s non-standard), and in a few years we can probably use C++ modules, which solve a lot more problems and are standard. IMO there is just not enough benefit to warrant this change given that it will probably be irrelevant in a few years.
1 Like
It will take some time until LLVM can start using C++ modules.
I switched a long time ago from headers guards to pragma once. Header guards are verbose and error prone. There were too many unnoticed copy-and-paste errors.
1 Like
Clang’s -Wheader-guard is your friend there, unless you butcher your header guards enough that they’re both have an edit distance of more than 50% from the other.
1 Like
Clang’s -Wheader-guard is your friend there
This looks like a crutch to me (I’m part of the crowd that is quite annoyed by these guards as well).
Unless we know of a platform we support that does not support #pragma once, I have a hard time seeing why we should shy away from adopting such facility. The argument about a compiler we “might want to support in future” comes across as really dubious to me.
1 Like
The obvious experiment is to switch one file to pragma once and wait for the buildbots to scream.
I don’t understand why header guards causes code noise. It only takes 3 lines.
Also since #pragma is not standard, it may be possible that the compiler will have some problem with it. For example, the modules have problems with #pragma. e.g., [C++20][Modules] '#pragma once' is not well supported · Issue #58532 · llvm/llvm-project · GitHub and modules: `#pragma once` must appear before `#ifdef` when using `-fmodules` · Issue #38532 · llvm/llvm-project · GitHub.
1 Like
gcc and clang resolve symlinks when evaluating #pragma once, whereas MSVC doesn’t, so it’s inconsistent across platforms. I don’t think that’s a big concern for LLVM, but it was for Meta’s internal build system and led to #pragma once being discouraged for cross-platform builds. The Google and Chrome style guides also ban #pragma once, FWIW.
To be clear: I’m not bother by “noise” as in “it is annoying to read”, but rather as it is 3 lines I need to update every time I rename or move a file (maybe I’m doing more refactoring than most…).
(your mention about issues with modules, as well as behavior differences with symlinks mentioned by @smeenai look to me like very compelling argument to not allow this pragma).
