i am by no means a C++ expert, but isn't "pragma once" frowned upon?
replies(5):
I've built [CXXStateTree](https://github.com/ZigRazor/CXXStateTree), a modern C++ header-only library to create hierarchical state machines with clean, intuitive APIs.
It supports: - Deeply nested states - Entry/exit handlers - State transitions with guards and actions - Asynchronous transitions with `co_await` (C++20 coroutines) - Optional runtime type identification for flexibility
It's ideal for complex control logic, embedded systems, games, robotics, and anywhere you'd use a finite state machine.
I’d love feedback, use cases, or contributions from the community!
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.)
They don't. They are not C++ and at most they are compiler-specific.
It's fine if you opt to not write C++ and instead target specific compilers instead. Just don't pretend it's not frowned upon or kosher.
Since you seem to be more knowledgeble about this, I'm curious to know which C++ compilers lack support? I know that at least the 3 big ones do (GCC, Clang, and MSVC) and they have for a very long time.