Also when you want to memory map a file/have live objects in shared memory, or in general have your in-memory & serialized structures be the same.
I don't know, but I tried using protocol buffer once for mapbox vector files, the resulting C++ header was huge. It had templates and all sort of things, something like more than 1000 lines.
Cap'n'proto is more or less abandoned I believe.
But it and the flatbuffer approach gives very fast serialization and deserialization speed (essentially takes 0 times) but you pay a cost when you later access data, because it extracts the values you need on demand from the raw bytes.
I'm not sure it would often make much sense overall.
> Cap'n proto is more or less abandoned I believe
As maintainer of capnproto-rust, I beg to differ. :)
Cap'n Proto is indeed actively maintained, and here at Sandstorm we depend on it every day as a core piece of our infrastructure.
Re:Protocol Buffers v3.0.0 released
by ocdtrekkie on Friday July 29, 2016 @03:19PM
(#12189251)
I would be very hesitant to call Cap'n Proto "abandoned". The Cap'n Proto developer is actively building a platform on top of it, and implements features in it as necessary, and as far as I've seen, actively works with pull requests for other features as well.
https://github.com/sandstorm-io/capnproto/commits/master https://github.com/sandstorm-io/capnproto/pulse/monthly
From FlatBuffers overview I see this comparison:
---
Protocol Buffers is indeed relatively similar to FlatBuffers, with the primary difference being that FlatBuffers does not need a parsing/ unpacking step to a secondary representation before you can access data, often coupled with per-object memory allocation. The code is an order of magnitude bigger, too. Protocol Buffers has neither optional text import/export nor schema language features like unions.
---
So are the newer ones useful mostly when serialization vs deserialization speed matters (https://google.github.io/flatbuffers/) ?