The whole point is that it's not supported and it's not standard, thus using #pragma once needlessly introduced the risk of having the code break.
You should ask yourself what are you doing and why are you using non-standard constructs that may or may not work, specially when it's rather obvious and trivial to just use include guards. Using #pragma once isn't even qualify as being clever to gain anything.
The whole point of C/C++ is knowing your environment. It's not Java, it's not TypeScript. It's one level above assembly, and if you change the compiler and things break, then it's your fault.
If the standards still don't have a proper replacement for include guards, then too bad for the standards. The C++ standard wasn't aware of multithreading before C++11, this didn't stop people from writing multithreaded programs.
As to why - #pragma once is just cleaner to look at.
Lots of things in C/C++ are nonstandard or optional, like the existence of optimization flags. Nevertheless, it's supported by literally every compiler I can think of for at least the last decade. I had to get into weird interpreters written in Python for university projects before I found anything that didn't support it.
Plus, it's nicer to read than #ifndef FOO_BAR_BAZ_PROJ_DIR1_DIR2_DIR3_FILE_H
I have genuinely encountered problems due to traditional include guards: in a project I worked on, they had been copied and pasted to one of the headers without being changed properly, but not included in the same translation unit so it went undetected. I noticed it when I needed to use them differently, at which point I got a mysterious compiler error. Admittedly, that was easily fixed, but naturally I checked if a similar problem existed in other files and sure enough it did. Now I need to decide whether to fix all those too and where to draw the line. Time and mental energy wasted for no reason.
I don't want to hear about how extra tooling could have avoided the problem. Using pragma once would have avoided the problem! It's simpler, less effort in the first place, needs no extra tooling and works everywhere in practice.
> What major compiler does not support it?
The whole point is that it's not supported and it's not standard, thus using #pragma once needlessly introduced the risk of having the code break.
You should ask yourself what are you doing and why are you using non-standard constructs that may or may not work, specially when it's rather obvious and trivial to just use include guards. Using #pragma once isn't even qualify as being clever to gain anything.
The whole point of C/C++ is knowing your environment. It's not Java, it's not TypeScript. It's one level above assembly, and if you change the compiler and things break, then it's your fault.
If the standards still don't have a proper replacement for include guards, then too bad for the standards. The C++ standard wasn't aware of multithreading before C++11, this didn't stop people from writing multithreaded programs.
As to why - #pragma once is just cleaner to look at.
> the standards still don't have a proper replacement for include guard
It does with modules... and in ten year if modules support is widespread, I'll consider stoping using pragma once.
Lots of things in C/C++ are nonstandard or optional, like the existence of optimization flags. Nevertheless, it's supported by literally every compiler I can think of for at least the last decade. I had to get into weird interpreters written in Python for university projects before I found anything that didn't support it.
Plus, it's nicer to read than #ifndef FOO_BAR_BAZ_PROJ_DIR1_DIR2_DIR3_FILE_H
#endif /* FOO_BAR_BAZ_PROJ_DIR1_DIR2_DIR3_FILE_H */
On every file.
That is a lot of words to say "none".
I have genuinely encountered problems due to traditional include guards: in a project I worked on, they had been copied and pasted to one of the headers without being changed properly, but not included in the same translation unit so it went undetected. I noticed it when I needed to use them differently, at which point I got a mysterious compiler error. Admittedly, that was easily fixed, but naturally I checked if a similar problem existed in other files and sure enough it did. Now I need to decide whether to fix all those too and where to draw the line. Time and mental energy wasted for no reason.
I don't want to hear about how extra tooling could have avoided the problem. Using pragma once would have avoided the problem! It's simpler, less effort in the first place, needs no extra tooling and works everywhere in practice.
Maybe you should ask why you're using a non-standard compiler if it's not supported.
Not being part of the official standard doesn't necessarily mean it's not well supported.