re: #pragma once

steven — Fri, 18 Apr 2008 02:31:47 GMT

I generally use both. #pragma once really is a very useful thing. Pragmas are supposed to allow for implementation-specific behaviour. I don't really see a problem with its behaviour being copied in another implementation. Apparently, the creators of GCC agree because the feature was un-deprecated in GCC 3.4 (release in 2004).

The Wikipedia entry on #pragma once (http://en.wikipedia.org/wiki/Pragma_once) mentions this. And indeed a simple test shows there are no warnings when using it (gcc version 4.2.2 on my system).

re: #pragma once

int19h — Fri, 18 Apr 2008 23:50:00 GMT

The reason why the GCC folks are backing out of it, and why the ISO committee will never approve it, is because it is nearly impossible to define the semantics of having "#pragma once" in a header in a proper fashion, even on a single platform. Specifically, the issue is with determining that the file being included now is one of those that have been included earlier.

Do we just compare path names? What if a file is referenced using two different relative pathnames? Do we always resolve to absolute, and then compare? Alright, then what about symbolic links and hardlinks - do we bother to check for those, or not? Note that these do not have to be on the file itself, but also on any of the directories in the path, so we'd have to check for them all. And when hardlinks are involved, on some platforms (all Unix-likes?), there's no single "primary" file name - they're all the same. Then, of course, there are network shares and UNC pathes - if, say, I share my INCLUDE folder, and then reference the same header twice, once using full UNC path, the second time using a local filesystem path, does the compiler still have to detect that? What if I'm referencing a remote server which shares the same folder under two different names? etc...

The only bulletproof way here is to compare the contents of files (or a sufficiently strong hash), but then you have to read the entire file anyway, so there isn't a huge speed benefit. On the other side, gcc at least can optimize the common header-guard pattern so that it's not any slower than #pragma once; any other compiler can do the same (and indeed, many do, though not, as I understand, MSVC).

On a side note, by far the easiest way to ensure that header guards are unique and also stand out is to use GUIDs for them.