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).
#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
- It is just unnecessary noise and verboseness.
C++17 is standard,
#pragma once is non-standard. So… I can easily imagine such a compiler.
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.
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.
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.
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.
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.
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.
#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.
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).