Capn Proto C Serialization

Key Features

* You can implicitly cast any compiled Cap’n Proto struct reader/builder type directly to DynamicStruct::Reader/DynamicStruct::Builder. Similarly with List and DynamicList, and even enum types and DynamicEnum. Finally, all valid Cap’n Proto field types may be implicitly converted to DynamicValue. * You can load schemas dynamically at runtime using SchemaLoader (capnp/schema-loader.h) and use the Dynamic API to manipulate objects of these types. MessageBuilder and MessageReader have methods for accessing the message root using a dynamic schema. * While SchemaLoader loads binary schemas, you can also parse directly from text using SchemaParser (capnp/schema-parser.h). However, this requires linking against libcapnpc (in addition to libcapnp and libkj) – this code is bulky and not terribly efficient. If you can arrange to use only binary schemas at runtime, you’ll be better off. * Unlike with Protobufs, there is no “global registry” of compiled-in types. To get the schema for a compiled-in type, use capnp::Schema::from(). * Unlike with Protobufs, the overhead of supporting reflection is small. Generated .capnp.c++ files contain only some embedded const data structures describing the schema, no code at all, and the runtime library support code is relatively small. Moreover, if you do not use the dynamic API or the schema API, you do not even need to link their implementations into your executable. * The dynamic API performs type checks at runtime. In case of error, it will throw an exception. If you compile with -fno-exceptions, it will crash instead. Correct usage of the API should never throw, but bugs happen. Enabling and catching exceptions will make your code more robust. * Loading user-provided schemas has security implications: it greatly increases the attack surface of the Cap’n Proto library. In particular, it is easy for an attacker to trigger exceptions. To protect yourself, you are strongly advised to enable exceptions and catch them.