yes, it means "zero allocations after state tree building".
Thank you for the suggestions, I think we could separate target with compilation switch. If you want you can open an issue on the repo.
Thank you so much
In some Embedded areas where safety is of high concern following the Motor Industry Software Reliability Association (MISRA) guidelines is a requirement.
There may be no heap at all and memory must be pre-allocated at system initialization. Otherwise CXXStateTree sounds like it could be very useful in my Embedded devices, which rarely have enough Flash or RAM space, which is the nature of the work.
I was about to complain about the use of strings in both libraries, both for the lack of type safety as well as the possible runtime allocation, but then I looked at the assembly for the sml example and there are no strings in the binary other than the obvious "send" one.
What exactly happened there? It looks like make_transition_table() is doing some serious magic. Or are the state transitions evaluated at compile-time given that there is no input in the example, and then the transition table gets compiled out?
Anyway, I think it would help OP's library to have some assembly output in the readme as well.
Looks like SML is using user-defined literals [0, 1] to effectively pre-process the string literal into state/event objects. Looks like the string itself is turned into a template parameter in the process and I believe those shouldn't show up in the compiled code (maybe unless there's some mangling-related thing going on?)
> 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?
TIL about the existence of a passionate #pragma once hating subculture.
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.
it's absolutely not frowned upon in 2025. All the compilers that matter (GCC, Clang and MSVC) support and have supported them for two decades. Major projects use #pragma once internally - I see files using it in Qt, LLVM, etc.
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.
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.
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
Nice and compact. I only wound have two nitpicks:
The Readme sais "zero heap allocations" but the code uses list and unordered map and moves, did you mean "zero allocations after state tree building"?
Also for embedded it would be useful to separate all in/out, dot export etc. to a second library that you can omit on small targets.
yes, it means "zero allocations after state tree building". Thank you for the suggestions, I think we could separate target with compilation switch. If you want you can open an issue on the repo. Thank you so much
In some Embedded areas where safety is of high concern following the Motor Industry Software Reliability Association (MISRA) guidelines is a requirement.
There may be no heap at all and memory must be pre-allocated at system initialization. Otherwise CXXStateTree sounds like it could be very useful in my Embedded devices, which rarely have enough Flash or RAM space, which is the nature of the work.
https://misra.org.uk
I think it is possible to create a version with 0 heap allocation, try to open an issue with this feature request, we can see how to that togheter
Thank you.
how is it better than https://github.com/boost-ext/sml ?
there are about 1 million c++ state machines, and sml happens to be the best, or one of them. how does yours differentiate?
I was about to complain about the use of strings in both libraries, both for the lack of type safety as well as the possible runtime allocation, but then I looked at the assembly for the sml example and there are no strings in the binary other than the obvious "send" one.
What exactly happened there? It looks like make_transition_table() is doing some serious magic. Or are the state transitions evaluated at compile-time given that there is no input in the example, and then the transition table gets compiled out?
Anyway, I think it would help OP's library to have some assembly output in the readme as well.
Looks like SML is using user-defined literals [0, 1] to effectively pre-process the string literal into state/event objects. Looks like the string itself is turned into a template parameter in the process and I believe those shouldn't show up in the compiled code (maybe unless there's some mangling-related thing going on?)
[0]: https://en.cppreference.com/w/cpp/language/user_literal.html
[1]: https://github.com/boost-ext/sml/blob/f232328b49adf708737bef...
Thanks, I didn't know that was a thing.
Related idea for those using python: https://github.com/baymotion/smax.
I want to create a python binding with PyBind11 and create a simple interface with a very good performance for Embedded systems
i am by no means a C++ expert, but isn't "pragma once" frowned upon?
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?
> I don't understand what you're saying here. #pragma once does the job that include guards used to do, (...)
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.
TIL about the existence of a passionate #pragma once hating subculture.
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.
it's absolutely not frowned upon in 2025. All the compilers that matter (GCC, Clang and MSVC) support and have supported them for two decades. Major projects use #pragma once internally - I see files using it in Qt, LLVM, etc.
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
I use a guid. (A different one each time, of course.)
> 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?
> 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.
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.
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.
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
vcpkg it
You can open an Issue on that on the repo (https://github.com/ZigRazor/CXXStateTree/issues) so we can track these changes.
Another idea is to create a Python binding with a release of a package