31–37 of 37 posts
i am by no means a C++ expert, but isn't "pragma once" frowned upon?
Earlier quoted context omitted.
Does anyone write those by hand anyway in any kind of project the size where it would matter? #pragma once is broken by design
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
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
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.
Earlier quoted context omitted.
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.…
Earlier quoted context omitted.
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.…
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
Earlier quoted context omitted.
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-t…
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…
Earlier quoted context omitted.
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…
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.