Hacker News Reader

Comment by rlkf | Hacker News Reader

A variant of this is to mandate that every header #define a documented symbol, and then have a #ifndef guard for this around the inclusion of the header.

View on HN

The standard practice of putting the ifndef guard inside each header is specifically optimized by compilers, though I don't recall where I read that.

I don't know why this is downvoted. This is exactly how it is.

The first time the compiler reads the include file, it remembers where the corresponding #endif is for each #if. The next time the file is included, the compiler can skip over the whole included file. There is no performance advantage from outsourcing the conditional to every including location.

Putting an ifndef guard at the location where the file located is not workable. It's terrible boilerplate. To the relatively simple '#include <A.h>' another variable that must be synchronized with dependencies gets added. Plus 2-3 lines for the conditional. At each including location.

IIRC, this is documented in the CPP part of the GCC manual. Whenever a header file is completely enclosed in a ifndef guard, and that guard is still defined, it will skip the whole file.

Another option is "#pragma once"; it's non-standard, but every popular C compiler (even MSVC) understands it, and has the advantage that there's no risk of accidentally using the same include guard for more than one header file.

Windows compilers were the first to have it, naturally MSVC understands it.

All production compilers now support `#pragma once`, so the traditional `#include` guard is almost totally obsolete.

The only plausible exceptions are in proprietary compilers for microcontroller SDKs.

I very rarely encounter #pragma once in the wild personally, and I still always use old school #ifndef guards myself. I can't really see a reason to change: it's not a huge amount of typing, it works everywhere, it's very explicit and not magical.

For instance out of the top of my head I don't remember how #pragma once decides what constitutes the same include file. If you have symbolic links, or absolute and relative paths for instance, how does it work? I'm sure I can find the answer in the compiler's documentation, but with #ifndef I don't even have to, it's obvious what's going to happen.

I would personally argue that old school guards should be preferred because of this and the fact that they're standard, but I don't feel super strongly about it.

Wouldn't it be as simple as maintaining a bloom filter containing the absolute paths of every included file encountered so far? Whenever you encounter #pragma once you check if the file is already present in the bloom filter and return early if it is. If it's a new file you add the file name to the bloom filter and continue processing.

It probably even more memory efficient (albeit insignificant in the grand scheme of compiler memory usage) for the compiler to just maintain the bloom filter and not have to deal with hundreds of otherwise unused preprocessor symbols, one per include file.

Bloom filter can have false positives.

The typical argument against pragma once is that it's unclear what should happen if two different hard link paths are used to include a file with the same inode (along with similar situations on Windows or with files on network drives). That is to say, in general, there is no consistent and portable "true" absolute path that uniquely identifies file(s) as conceptually having the same underlying storage.

In practice, I have never actually seen a problem arise. The most likely real trigger would probably be a mix of including a library through a path that indicates a specific version and including it through a path that uses a "latest stable" link. That is already fragile and asking for trouble, though.

I've seen terrible bugs in the past where there were multiple incompatible versions of a header file in a codebase, but nobody noticed because both headers used the same guard variable name, so the header that was included first always won.

Yes, this is the usual failure mode. It happens quite often, because nothing checks for unique or correct guard names.

Failing to switch to `#pragma once` when it becomes permissible is reckless and irresponsible.

I'd think it would be much easier for a preprocessor to determine that it is done with a file, once it encounter that pragma, instead of having to scan for the corresponding #endif (not sure if it'll dare to scan from the back and hope that all #if/#ifdef, #endif pairs match or whether it diligently checks those every time).

You may imagine that you are helping the compiler avoid error, but the fact is that real compilers, when they encounter `#include` guards, translate therm implicitly to `#pragma once`, and move on. The compiler is better at it than you are.

Meanwhile, you are exposing yourself to subtle bugs resulting from multiple headers that define the same guard name, as noted nearby. So, your imagined virtue is folly.

Reply on news.ycombinator.com