It's actually pretty cheap on ARM (2 cycles ), if the message IDs are consecutive, due to TBB/TBH , and GCC will use it when appropriate. Not sure if x86 has an equivalent.
That statement about switch inefficiency is simply not true, except for sparse case values.
But since one can generally choose those values (and they're often a running enum anyways), it's really a non-issue.
For sparse case, it's better to use a hash table. Perhaps a build phase to generate a perfect hash (https://en.wikipedia.org/wiki/Perfect_hash_function) to map each possible input value to continuous range of integer values.
Even for sparse case values the compiler will emit a binary search once the list of labels is long enough.
I guess the main issue is that the compiler will need to also ensure no value outside the expected set can match a case statement either (no match and default cases), which kinda negates the benefit.
Maybe there are cases this is generated, anyone seen compiler generating those?
I wonder whether it is possible to generate reversible (almost) perfect "hashes"?
I mean a hash where every unique input value is guaranteed to map to a unique output value. Because this kind of hash could be used to handle no-match/default case safely.
namespace cc = comms_champion;
Protocol::~Protocol() noexcept = default;
const QString& Protocol::nameImpl() const
static const QString& Str("Demo");
} // namespace cc_plugin
} // namespace demo
the ublox example seems a reasonably complex protocol of messages.
However, I'm not really sold on the framework to do it this way.
Using C/C++ for embedded systems external communications feels like building a house out of matches.
Sure, there's tooling to help fire proofing things a bit, like static analysis and so on. You see, it's important to spray some fire retardant on the match house.
But wouldn't it be so much nicer to have a construction material other than matches for this purpose...
Currently limited microcontroller architecture support is one of the biggest issues with it.
Rust based RTOS would also be helpful for medium size devices. Of course small devices are fine on bare metal.
I would have guessed C or C++. Maybe they're not great for the purpose but they're also just about the only game in town, no?
While C++ is easier to write, for very low level code, it is harder to maintain when you need to understand all of the side effects to maintain code safety.
C++ compiler support is also sometimes not available. (And of course it's very like there'll be no Rust compiler available either in this case.)
Actually, does anyone know if FORTRAN is ever used for embedded applications?
It was used for a fair number of control systems in the 1980s and 1990s.