> Does anyone write those by hand anyway in any kind of project the size where it would matter?
I think you're suggesting that you don't need to make up the names for include guards because all tools / IDEs for C++ write them for you automatically anyway. But that isn't my experience. Many IDEs don't write include guards for you automatically ... because everybody uses #pragma once already.
> #pragma once is broken by design
I think you're referring to the historical problem with #pragma once, which is that it can be hard for the compiler to identify what is really the same file (and therefore shouldn't be included a second time). If you hard link to the same file, or soft link to it, is it the same? What if the same file is mapped to two different mount points? What if genuinely different files have the same contents (e.g., because the same library is included from two different installation paths)? In practice, soft/hard links to the same file are easily detectable, and anything more obscure indicates such a weird problem with your setup that you surely have bigger issues. #pragma once is fine.
(Historically, it also had the benefit that compilers would know not to even re-read the header, whereas with traditional include guards they would need to re-include the file (e.g. in case the whole file is not wrapped in the #ifdef, or in case something else has undefined it since) only to then discard the contents. I've even seen coding guidelines requiring external include guards wrapped around every use of headers with #include <...>. Yuck! But modern compilers can work out when include guards are meant to mean that so today that difference probably no longer exists.)
I don't understand what you're saying here. #pragma once does the job that include guards used to do, but with less work, and in a less error prone way. How is it broken, and how is the size of a project relevant?
Even if you don't write header guards by hand you get issues. The amount of time I got bitten by someone naming a file "widget.h" or "utils.hpp" three levels of libraries down with the corresponding #ifndef WIDGET_H which broke the build in incredibly mysterious ways...
No, this is completely wrong. Pragma once is non-standard compiler directive. It might be supported by some compilers such as msvc but technically it is not even C++.
There are only two options: include guards, and modules.
In the C++ community (as lots of other things are), rejecting `#pragma once` is a long-standing tradition of worshipping the decaying body of prehistoric compilers for
It's unclear what benefits this approach has achieved, but don't disturb it, or else.
You'll see a fairly even split amongst S-tier, "possibly headed for standardization" level libraries. I'd say there's a skew for `#ifndef` in projects that are more "aspires to the standard library" and for `#pragma once` in projects that are more focused on like a very specific vertical.
`#pragma once` seems to be far preferred for internal code, there's an argument for being strictly conforming if you're putting out a library. I've converted stuff to `#ifndef` before sharing it, but I think heavy C++ people usually type `#pragma once` in the privacy of their own little repository.
please someone open an Issue on the repo(https://github.com/ZigRazor/CXXStateTree/issues), to substitute the #pragma once with the more classic include guards with the motivation explained in the comment.
Thank you
No, it is the way. Edit: no one has time for inventing unique names for include guards.
Does anyone write those by hand anyway in any kind of project the size where it would matter?
#pragma once is broken by design
> Does anyone write those by hand anyway in any kind of project the size where it would matter?
I think you're suggesting that you don't need to make up the names for include guards because all tools / IDEs for C++ write them for you automatically anyway. But that isn't my experience. Many IDEs don't write include guards for you automatically ... because everybody uses #pragma once already.
> #pragma once is broken by design
I think you're referring to the historical problem with #pragma once, which is that it can be hard for the compiler to identify what is really the same file (and therefore shouldn't be included a second time). If you hard link to the same file, or soft link to it, is it the same? What if the same file is mapped to two different mount points? What if genuinely different files have the same contents (e.g., because the same library is included from two different installation paths)? In practice, soft/hard links to the same file are easily detectable, and anything more obscure indicates such a weird problem with your setup that you surely have bigger issues. #pragma once is fine.
(Historically, it also had the benefit that compilers would know not to even re-read the header, whereas with traditional include guards they would need to re-include the file (e.g. in case the whole file is not wrapped in the #ifdef, or in case something else has undefined it since) only to then discard the contents. I've even seen coding guidelines requiring external include guards wrapped around every use of headers with #include <...>. Yuck! But modern compilers can work out when include guards are meant to mean that so today that difference probably no longer exists.)
I don't understand what you're saying here. #pragma once does the job that include guards used to do, but with less work, and in a less error prone way. How is it broken, and how is the size of a project relevant?
3 replies →
Even if you don't write header guards by hand you get issues. The amount of time I got bitten by someone naming a file "widget.h" or "utils.hpp" three levels of libraries down with the corresponding #ifndef WIDGET_H which broke the build in incredibly mysterious ways...
https://github.com/search?q=ifndef+WIDGET_H&type=code
1 reply →
> No, it is the way.
No, this is completely wrong. Pragma once is non-standard compiler directive. It might be supported by some compilers such as msvc but technically it is not even C++.
There are only two options: include guards, and modules.
What major compiler does not support it?
6 replies →
Yes, it is non-standard, but I don't know any compiler that does not support it.
All terrestrial compilers support `#pragma once`.
In the C++ community (as lots of other things are), rejecting `#pragma once` is a long-standing tradition of worshipping the decaying body of prehistoric compilers for
It's unclear what benefits this approach has achieved, but don't disturb it, or else.
You'll see a fairly even split amongst S-tier, "possibly headed for standardization" level libraries. I'd say there's a skew for `#ifndef` in projects that are more "aspires to the standard library" and for `#pragma once` in projects that are more focused on like a very specific vertical.
`#pragma once` seems to be far preferred for internal code, there's an argument for being strictly conforming if you're putting out a library. I've converted stuff to `#ifndef` before sharing it, but I think heavy C++ people usually type `#pragma once` in the privacy of their own little repository.
- `spdlog`: `#pragma once` https://github.com/gabime/spdlog/blob/v1.x/include/spdlog/as...
- `absl`: `#ifndef` https://github.com/abseil/abseil-cpp/blob/master/absl/base/a...
- `zpp_bits`: `#ifndef` https://github.com/eyalz800/zpp_bits/blob/main/zpp_bits.h
- `stringzilla` `#ifndef` https://github.com/ashvardanian/StringZilla/blob/main/includ...
I've avoided #pragma once because of reports that it slows down gcc/g++: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58770
But given that I haven't seen any mention of that issue in other comments, I wonder if it really is an issue.
please someone open an Issue on the repo(https://github.com/ZigRazor/CXXStateTree/issues), to substitute the #pragma once with the more classic include guards with the motivation explained in the comment. Thank you