mercury
mercury copied to clipboard
hg_proc size pass
Was thinking about the proc issues talked about in #79 and had the following idea:
- have a new type of proc operation - HG_GET_SIZE, which increments two (new) size values in the proc data structure - the type's size and, if applicable, the variable-length size of any (containing) bulk handles. The var-length is expected to be attached to a bulk handle
- repurpose the proc workflow to:
- call proc on the input type(s) with HG_GET_SIZE
- determine whether to use eager mode or not (the size counters provide the necessary info)
- allocate needed data
- call proc again with HG_ENCODE
(the decode path would just need to track whether eager mode was used and otherwise be unchanged I think...)
There's a few benefits to this:
- no need to repeatedly check buffer sizes and do reallocation and such. You have exactly one alloc
- the HG_GET_SIZE implementation for most types we're interested in (C structs with some light variable-length data) is trivial.
- eager mode issues are resolved for arbitrary types
Is this a reasonable approach?
Sorry for not responding earlier, that's interesting I like the idea. Although that's still 2 passes :) Yes the proc component needs to be improved to get rid of the if size etc as much as we can I think.