The format gallery has some lovely examples. I was initially skeptical, but this is quite nice.
For other people who might not look as far, it seems that the main advantage of this over other solutions (PB, Cap'n Proto, Flatbuffers, etc.) is that you can describe types that don't originate in the Kaitai ecosystem, and come out with code that can correctly read and manipulate those datatypes.
One slightly unfortunate item -- I don't see anything about using the generated code in a zero-copy situation. The docs are not very detailed on the point of the generated API, so perhaps this capability is present and just not documented in an easy-to-find way. This is not fatal, it's just a slightly less than optimal state of affairs.
Reading the stream API ([1]), it seems this is correct. There is nothing like Cap'n Proto-like direct-access semantics, nor even anything on the level of ZeroCopyInputStream [2].
For other people who might not look as far, it seems that the main advantage of this over other solutions (PB, Cap'n Proto, Flatbuffers, etc.) is that you can describe types that don't originate in the Kaitai ecosystem, and come out with code that can correctly read and manipulate those datatypes.
One slightly unfortunate item -- I don't see anything about using the generated code in a zero-copy situation. The docs are not very detailed on the point of the generated API, so perhaps this capability is present and just not documented in an easy-to-find way. This is not fatal, it's just a slightly less than optimal state of affairs.
Reading the stream API ([1]), it seems this is correct. There is nothing like Cap'n Proto-like direct-access semantics, nor even anything on the level of ZeroCopyInputStream [2].
[1]: https://github.com/kaitai-io/kaitai_struct_cpp_stl_runtime/b...
[2]: https://developers.google.com/protocol-buffers/docs/referenc...