Hacker News new | ask | show | jobs
by SuperV1234 33 days ago
This cost is not significant nowadays, it's the frontend/parsing time.

You can also use `#pragma once` which works everywhere, is nicer, and technically needs less work by the compiler, but compilers have optimized for include guards since a long time ago.

Some random measurements I found: https://github.com/Return-To-The-Roots/s25client/issues/1073
1 comments
vanderZwan 33 days ago
Yes, I've heard that before, but comments like this one in your linked issue still make me wonder:

> at least for gcc and Visual Studio using #pragma once has a significant impact. The fact is, the compiler does not need to continue parsing the whole file when reaching a #pragma once. otherwise the compiler always needs to do it even if the include guard afterwards will avoid double processing of the content afterwards.

As written the explanation for these optimizationst suggest that both "pragma once" and include guard optimization still requires opening and closing the file each time an include is encountered, even if you bail after parsing the first line. Is that overhead zero? Or are the optimizations explained poorly and is repeatedly opening/closing the file also avoided?

Either way, do you know what causes the slowdown as a result of including <meta>?

link
gpderetta 33 days ago
The compiler doesn't need to open the same file multiple times. It can remember if a a file is guarded or not every time it sees its name.

My understanding is that this is an optimization that has been available for a very long time now.

The only issue is if a file is referred through multiple names (because of hard links, symlinks, mounts). That might cause the file to be opened again, and can actually break pragma once.

link
gpderetta 33 days ago
gcc actually documents this behaviour: https://gcc.gnu.org/onlinedocs/cppinternals/Guard-Macros.htm...
link
vanderZwan 33 days ago
Thank you for explaining and looking up the link, it's appreciated! :)
link
Quekid5 33 days ago
The overhead isn't zero, but with SSDs (and filesystem caches in the gigabytes these days) it's damn near insignificant in pure terms of opening files and such.
link