[Xcb] about api changes

[Christoph Pfister]

2007/6/7, Christoph Pfister <christophpfister at gmail.com>:
> 2007/6/7, Christoph Pfister <christophpfister at gmail.com>:
> <snip>
> > Ideally (at least imho) we wouldn't have those iterator structures anymore
> > (okay - this might be a bit heavy for an api breakage), but instead elements
> > with adjacent memory positions where possible (/me has to investigate a bit
> > there and look how realistic that would be).
> <snip>
>
> Okay - I realised that data is sometimes interleaved (e.g. depth /
> visual / depth / visual). But a problem remains - when can I simply
> increase the pointer and when do I have to use the _next function
> (right - if a _next function is present it has to be used in the
> current situation).
> Hmhmhm - that would still be possible with an approach where you have
> xcb_...s() and xcb_..._length() (btw - why is that function not called
> _count or something like that?); you would have a xcb_..._next()
> function for interleaved data which would be hopefully sufficent.
> (Same way to deal with the items as now: if _next is present you have
> to use it otherwise simply increment the pointer).
>
> Christoph

Okay - I had a discussion with Thomas about that on irc and rethought
some points afterwards. My proposal looks the following way now (I'll
update the wiki page to that too):
- For elements which occupy adjacent memory positions you have two
functions - for example "xcb_visualtype_t *xcb_depth_visuals(...)" and
"int xcb_depth_visuals_length(...)". To get to the next element you
simply increment the pointer.
- For elements which don't occupy adjacent memory positions you have
an iterator struct containing only a pointer to the data. You need
three functions - for example "xcb_screen_iterator_t
xcb_setup_roots_iterator(...)", "int xcb_setup_roots_length(...)" and
"void xcb_setup_next(xcb_screen_iterator_t *i)".

This way it should be clear when to use *_next(...) and when not (you
can assume that whenever you do something else than dereferencing the
data pointer of a *iterator_t you're on the wrong path).

Comments?

Christoph