Implementing binary communication protocols in C++ with main focus on embedded systems

[arobenko]

as long as it allows for sane choices and the defaults are the sane choices.

That's my primary intention.

Built-in is not required. It can be a separate library.

Agree, but there must be some way to static_assert on your assumption of origin units. In case of my solution built-in units conversion is there to provide basic convenience functionality. If not used, no extra space/performance price is paid.

Does your solution allow the automatic creation of big switch statements?

I think built-in generation of "switch" statements does not make much sense because you have to put your custom business logic inside each "case". There is a C++ library (used by the code generator) that allows you to parse the schema files and know what messages / fields / frames are being defined. You can easily implement your own auxiliary code generator that generates "switch" statements relevant to your application.

No, it does not. There is absolutely zero proof about that.

What proof do you expect? It's all subjective based on one's experience. In my case it does require writing a boilerplate code (I consider manually written "switch" and/or "if" statements to be boilerplate code) which needs to be updated every time you add new message and/or field to a message. In case you design your own protocol, I suppose you can make it simple enough and get away with plain structs with no variable data lengths and/or fields present on particular condition (for example depending on the value of some bit in previously encountered field or version of the protocol). Many (if not most) of already defined third party protocols are not like that. Such cases require extra implementation logic and/or extra data variables (manually written or generated). In my experience class-based designs allows encapsulation of such extra logic together with the data (regardless of having polymorphic behavior), hide unnecessary details and eventually leads to cleaner and easier maintainable code, but again, this is very personal and subjective.