I understand the standard guidance for the C++ classes that Cap'n Proto generates is that you should mirror them with in-memory structs that you can mutate. So Cap'n Proto is first and foremost a serialization library, and only incidentally a data structure description language (at least, until https://groups.google.com/forum/#!searchin/capnproto/refcounted%7Csort:date/capnproto/Reg0wInHBdY/ftJUP3iTCQAJ happens). Fine. But what if I plan to treat my data immutably? The appeal of skipping out on the conversion boilerplate is quite great. Are there still other reasons why I might still want to schlep my Cap'n Protos into another format? Some I can think of:
* Reads will still be slightly slower, since all of the offset calculation and security validation. Intuitively, how would you tell if this is too much? * In general, you'd have to assume that the struct is dynamically sized, and thus you cannot ever stack allocate it. (You would want some sort of refcounted version of MyStruct::Reader, to manage the lifetime of the memory?) Are there other considerations? -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/d181151b-4900-457e-bca9-efa496eb318d%40googlegroups.com.
