Hi Junhyun, I think that, at present, the only thing that would break your assumptions is Orphanage::referenceExternalData(). You could, of course, document that your MessageBuilder does not permit referencing external data.
Other than that, I think your assumptions currently hold -- but I don't know if I'd be comfortable guaranteeing them. It's better if you can look at what getSegmentForOutput() returns and handle any discrepancies between that and what you were expecting. -Kenton On Thu, Aug 16, 2018 at 9:34 PM, Junhyun Shim <[email protected]> wrote: > Hi, > > I'm currently writing a custom impl. of MessageBuilder (with overridden > allocateSegment virtual method that produces moveable, shallow-cloneable > buffers), > that, after fleshing out the capnproto message as a whole, produces an > internal message object backed by a static array of those buffers for I/O. > > As you might have noticed, this design builds on the assumption that the > number of segments produced by getSegmentsForOutput() > does not exceed the number of calls made to allocateSegment() while > building the message. > Is this a safe guarantee? Can I even go on to assume that the base > pointers produced by getSegmentsForOutput() > are exactly the same as allocated segments and the only variation is in > their sizes? > > Or is there a chance that out-of-order initialization of root message > members might end up scrambling these orders? > > Best regards, > Jun > > -- > 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 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.
