[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