Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: CXXStateTree – A modern C++ library for hierarchical state machines

github.com

Post reply on HN
Print view View original

21–30 of 37 posts

Re: Show HN: CXXStateTree – A modern C++ library for hierarchical state machines

#21

Post by jcelerier »

motorest wrote: post #13
bogwog wrote: post #9

Earlier quoted context omitted.

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.

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.

Re: Show HN: CXXStateTree – A modern C++ library for hierarchical state machines

#22

Post by alt187 »

dgan wrote: post #6

i am by no means a C++ expert, but isn't "pragma once" frowned upon?

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.

Re: Show HN: CXXStateTree – A modern C++ library for hierarchical state machines

#23

Post by sam_bishop »

dgan wrote: post #6

i am by no means a C++ expert, but isn't "pragma once" frowned upon?

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.

Re: Show HN: CXXStateTree – A modern C++ library for hierarchical state machines

#24

Post by gpderetta »

AndriyKunitsyn wrote: post #19
motorest wrote: post #15

Earlier quoted context omitted.

> 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…

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…

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

Re: Show HN: CXXStateTree – A modern C++ library for hierarchical state machines

#26

Post by AlotOfReading »

motorest wrote: post #15
quietbritishjim wrote: post #12

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…

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.

Re: Show HN: CXXStateTree – A modern C++ library for hierarchical state machines

#27

Post by canyp »

wangii wrote: post #25

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.

Re: Show HN: CXXStateTree – A modern C++ library for hierarchical state machines

#28

Post by benreesman »

dgan wrote: post #6

i am by no means a C++ expert, but isn't "pragma once" frowned upon?

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

Re: Show HN: CXXStateTree – A modern C++ library for hierarchical state machines

#29

Post by aw1621107 »

canyp wrote: post #27
wangii wrote: post #25

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-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-ext/sml/blob/f232328b49adf708737bef...

Post reply on HN