Thanks for the suggestion. I'm having a little trouble applying it in practice though -- it may just that I'm having trouble navigating the api.
Is the relevant AnyStruct::Reader constructor I'll want to call Reader(_::StructReader reader)? A DynamicStruct::Reader (which is what I have) does have a _::StructReader field but I can't see any way to get access to it. It also has an as<> method which, if I could call is as as<AnyStruct> would do exactly what I want but that triggers a static assertion because kind<AnyStruct>() is Kind.OTHER, not Kind.STRUCT. I did actually manage to implement the scheme I had in mind using as<AnyStruct> and it worked just as expected -- but the code broke when I tried to compile it on a different machine. I must have been using a compiler that didn't check static_asserts initially. So I hope there's a way to work around the problem. c On Fri, Feb 17, 2017 at 11:03 PM, Kenton Varda <[email protected]> wrote: > Hi Christian, > > One way to do this: > > capnp::AnyStruct::Reader(myStructReader).getDataSection() > > This will return a kj::ArrayPtr<const byte> that points at the "data > section" of the struct, which contains the non-pointer fields. .begin() > gives you a direct pointer to the first byte. The data section comes before > the pointer section, so this is essentially a pointer to the start of the > struct. > > -Kenton > > On Fri, Feb 17, 2017 at 12:19 AM, <[email protected]> wrote: > >> Hi, >> I've been looking at the reflection api for a way to inspect the layout >> of the encoded data. Specifically what I've been looking for is a reliable >> way to find the word-offset of the beginning of a given struct. Is there a >> way to do that? >> >> For context, the reason I need it is that I need to keep some >> proto-encoded data up to date with small changes that come in occasionally. >> So I need a mechanism for representing just the deltas between two versions >> of a proto, and ideally a really simple way that works just on the binary >> encoded data. The data is mainly flat lists of structs. A simple approach I >> wanted to try was to simply xor the entire before- and after- binaries and >> then zipping the result. Before and after will be very similar so the xor >> should be mostly 0 and so zipping should shrink it down to hardly anything. >> Except there's a hitch: if just one of the structs changes size the other >> elements will shift around and not line up, and xor'ing won't cancel them >> out. But if I could determine where in the binary each element starts I can >> line corresponding elements up by 0-padding (which would be removed again >> when applying the update) and then the scheme should work. >> >> >> c >> >> -- >> 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]. >> Visit this group at https://groups.google.com/group/capnproto. >> > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Cap'n Proto" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/capnproto/2aPc1--JQtM/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > Visit this group at https://groups.google.com/group/capnproto. > -- 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]. Visit this group at https://groups.google.com/group/capnproto.
