On Wed, 28 Aug 2024 at 02:54, Arthur O'Dwyer via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
> My experience matches Tiago's: #pragma once Just Works, in every environment I have access to.
> But Gašper has said that his experience, in his environment, is different: #pragma once doesn't Just Work there. That is, to be precise, GCC handles the `#pragma once` syntax differently from how customers on that particular environment want it to be handled.
>
> It might be actually, practically useful, if someone with access to an environment like Gašper's, and GCC-hacking experience, would combine these to produce a compiler switch — something like `gcc -fpragma-once-hash-based`, or `-fpragma-once-timestamp-based`, or `-fpragma-once-something-else` — so that we could see what they are actually asking for. And then the GCC maintainers could consider whether to adopt an opt-in command-line switch like that. Then the few people in environments that require it, would put the switch into their build scripts, and then they could switch over to using `#pragma once` even in their environment.
>
> Right now I'm just seeing (a few) people saying "GCC's handling of #pragma once Doesn't Work for my environment," but with no concrete suggestions for how GCC ought to handle `#pragma once` in their environment.
Well, we don't have such suggestions. We don't know whether they
exist. Or, to phrase it differently, based on what we know, they
don't.
We are looking at a situation where you include the same header
multiple times via different paths, but those paths involve bind or
overlay mounts, and then the paths are different, the inodes are
different, mtimes may be
slightly different, and a #pragma once fails to recognize that we are
looking at a header that's already been seen. You can then fall back
on
content hashing if you like, but that's much slower than parsing an
include guard and skipping the file.
In other words, the quick and efficient "is it the same file?" checks
don't work, and the fallback that can give the correct answer is
prohibitively expensive.
The solution to the problem is the use of include guards, and
avoidance of #pragma once.
Okay, IIUC as far as you're concerned, the answer is:
- What would work, theoretically, is a hash of the file contents. The programmer could write `#pragma once // SOME_INCLUDE_GUARD_IDENTIFIER`, thus making the hash different whenever the identifier was different; this would have the same semantic effect as a full `#ifndef` include-guard. But, as you say, this would likely be slower than just using a plain include-guard. A plain include-guard wouldn't have to hash the whole file. Now, a plain include-guard would still have to read the whole file in order to find the `#endif`, because anything after the `#endif` would need to be parsed as usual. (Remember, in this environment the compiler can't tell if this is the same file that was encountered before, or a different file that just happens to begin with a matching `#ifndef` line.) Still, "basically grep" is likely to be measurably faster than "basically md5sum".
- You reject the hash-the-contents solution; therefore, you will never ever use `#pragma once`. Therefore it doesn't matter to your use-case whether we standardize it (for environments-that-aren't-yours) or not.
If your experience matches Gasper's experience and everyone-who-might-object-to-#pragma-once's experience, then it would appear that there's no technical objection to standardizing `#pragma once` for the environments that do support it (i.e. not yours).
–Arthur