On Wed, Mar 13, 2013 at 06:00:24PM -0400, Stefan Berger wrote:
> On 03/13/2013 04:52 PM, mdroth wrote:
> >On Wed, Mar 13, 2013 at 01:56:24PM -0500, Joel Schopp wrote:
> >>Add a sized buffer interface to qapi.
> >Isn't this just a special case of the visit_*_carray() interfaces? We
> >should avoid new interfaces if possible, since it adds to feature
> >disparities between visitor implementations.
>
> Yes, it's a special case and carray seems more general.
> However, I don't understand the interface of carray. It has a
> start_carray with all parameters given, then a next_carray and an
> end_carray. Why do we need multiple calls if one call (start_carray)
> could be used to serialize all the data already?
Visitors don't have any knowledge of the data structures they're visiting
outside of what we tell them via the visit_*() API.
For output, visit_start_carray() only provides enough information to
instruct a visitor on how to calculate the offsets of each element (and
perhaps allocate some memory for it's own internal buffers etc.)
For input, it provides enough to allocate storage, and calculate offsets
to each element it's deserializing into.
As far as what to do with each element, we need to make additional calls
to instruct it.
For example, a visitor for a 16-element array of:
typedef struct ComplexType {
int32_t foo;
char *bar;
} ComplexType;
would look something like:
visit_start_carray(v, ...); // instruct visitor how to calculate offsets
for (i = 0; i < 16; i++) {
visit_type_ComplexType(v, ...) // instruct visitor how to handle elem
visit_next_carray(v, ...); // instruct visitor to move to next offset
}
visit_end_carray(v, ...); // instruct visitor to finalize array
>
> Regards,
> Stefan
>
>
>
