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!
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.
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.
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.
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.