Using #pragma once

[rolandreichweinbmw]

Hi! How about using #pragma once in OpenBSW instead of randomly generated include guards?

https://en.wikipedia.org/wiki/Pragma_once

I can offer to help switching over the codebase.

Update: PR in #84

[rolandreichweinbmw]

Closing the discussion now that the PR is merged.

[marcmo]

Hi Roland,
there have been some concerns about the usage of the #pragma once after we merged your PR.
Some folks pointed out that there might be problems with symlinks. Since you have a lot of experience with bazel and here symlinks are used extensively, do you have any more insights here?

[lmgivelaccenture]

I tried locally to include files multiple times through soft and hard links, using #pragma once, and it isn't a problem for gcc or clang. Even hard-linked files get recognized as the same file and are not re-included.

From searching online, issues with #pragma once might arise when networked storage that suffers from clock skew is involved. Simulating this situation locally seems non-trivial so I wasn't able to confirm.

[rolandreichweinbmw]

By definition, #pragma once is not 100% equivalent to #ifdef include guards. However, the goal is basically the same. And in practice, they are easily interchangeable in projects.

#pragma once works on the level of file path identity, i.e. including the file only once from exactly the same location (no matter if hardlink/symlink or not).

For OpenBSW and many other projects (including bazel), this works pretty well.

It does not work if you construct a project layout with different symlinks, file copies etc. However, this is bad project setup and should be fixed anyway. (I haven't seen that issue in practical cases.)

In a big project that I switched to #pragma once, I've seen copy-paste errors with the previous #ifdef include guards where whole headers where copied over without changing the #include header guard symbols. However, #pragma once made individual files from it, all being included+compiled. The result was multiply defined symbols (C++ and preprocessor). But I considered this broken code anyway that needed to be fixed. I consider it a good thing that #pragma once discovered those issues and forced me to fix it properly.

Further, if code relies on certain #ifdefs from the include guards (e.g. of other headers) to produce code conditionally, this can be fixed indidually. And I consider it a good thing to separate the include guard mechanism from conditionally compiled code.

Apart from that, I'm not aware of practically relevant issues that can't reasonably be solved.

We have also done a performance comparison in a project with ~10000 headers and had a gain of ~2-3% from #pragma once. It's not something I need to rely on for switching to #pragma once, but at least it is as fast as #ifdef include guards.

[johannes-esr]

Since #84 is merged, I'll close this discussion.