[Xcb] GSoC: final C code mapping for <switch>
Christoph Reimann
chrr at arcor.de
Thu Jun 17 06:45:37 PDT 2010
Hi everybody,
I have finished almost all changes w.r.t. the code generator in the
meanwhile, and the last thing that remains is to decide on the final
mapping of <switch>.
(Just for the record: For the moment, I have decided on changing the
serialization code - it is now done elementwise, see previous post on
the list - simply because it's simpler and one could change it later
(if necessary for performance reasons) without touching the API. )
Now back to <switch>: I would prefer that the mapping is
a) one struct that takes all (bitcase) fields
b) that struct gets passed to request calls
example with pseudocode: XKB request <request name="SelectEvents"
opcode="1">, contains <switch name="details">
typedef struct xcb_xkb_select_events_details_t {
... all bitcase fields ...
} xcb_xkb_select_events_details_t;
xcb_void_cookie_t
xcb_xkb_select_events (xcb_connection_t *c /**< */,
xcb_xkb_device_spec_t
deviceSpec /**< */,
uint16_t
affectWhich /**< */,
uint16_t clear /**< */,
uint16_t
selectAll /**< */,
uint16_t
affectMap /**< */,
uint16_t map /**< */,
const xcb_xkb_select_events_details_t *details /**< */);
advantages:
- type-safe, i.e. no void* needed
- easy-to-use, no need to assemble the list manually
- if value-params are rewritten: replaces functions in util/aux
disadvantages:
- unused struct fields waste a bit memory
- if value-params are rewritten: breaks API (mapping for value-params
is currently const uint32_t *value_list)
Another suggestion by Peter Harris: map switch to a helper function
that populates a buffer, let the request function take s.th. like
const void *switch_list
example:
void *
xcb_xkb_select_events_details(uint16_t affectWhich, uint16_t clear,
uint16_t selectAll, /* fields needed for switch expr */
const
xcb_xkb_select_events_details_t *details);
(whether the void * buffer is allocated by the _details() function or
if it's better to supply it as an argument is not decided yet)
xcb_void_cookie_t
xcb_xkb_select_events (xcb_connection_t *c /**< */,
xcb_xkb_device_spec_t
deviceSpec /**< */,
uint16_t
affectWhich /**< */,
uint16_t clear /**< */,
uint16_t
selectAll /**< */,
uint16_t
affectMap /**< */,
uint16_t map /**< */,
const void *details /**< */);
advantages:
- one could still "hand-roll the request"
- if value-params are rewritten: does not break API
- if value-params are rewritten: helper function like those in
util/aux can still be generated automatically - however the number of
request functions is further increased
disadvantages:
- no type safety with void*
- for XKB <switch>: unneccessary, as (I think) it is most unlikely
that anyone assembles these manually
- at least 2 function calls necessary in order to complete the request
I am very interested in your opinions and I would like to have the
mapping for <switch> fixed before I start writing wrappers for XKB.
Thanks in advance,
all the best
Christoph
More information about the Xcb
mailing list