c6f3fb2529
Parametrized structs contain paramref expressions which refer to the value of a field defined in the context where the struct is used. Implementing the parametrized structs turned out to be somewhat easier than previously thought because the generator already had some support for type-parametrization because this is needed when case or bitcase refers to fields outside of the switch. So I decided to go with the flow and to implement the solution which best fits the current implementation. I did the following: * I provided a way to specify fieldref with an explicitely given type: This resulted in <paramref type="CARD8>fieldname</paramref> A paramref is just a fieldref with an explicit type. The type is necessary because there is no local field of that name where the type can be derived from. * then I tested it and made several changes in the generator such that it really works. Basically the generated code is as follows: * The parameter appears on the parameter list of the sizeof-function of the parametrized struct. When that function gets called, an appropriate argument is supplied. * The parameter also appears as an additional member of the iterator-struct for the iterator of lists of that parametrized struct. This way, the next-function can get the value of that parameter from the iterator. When the iterator is created, this iterator-member is set accordingly. * When the paramref appears in the length-expression of a list, then the parameter appears on the parameterlist of the "length" and "end" functions. When these functions get called, an appropriate argument is supplied. Some comments: * I did not implement inline structs. This would probably have been more complicated, and at least some additional effort. But that can be implemented later if needed. (Inline structs could probably use some code from switch-case/bitcase which is already kind of an inlined struct but one has to be careful not to break the functionality of switch-case/bitcase. Support for inline structs inside lists must probably be implemented from scratch...) * The paramref expression refers to a field of the same name in the struct/request/... where it is used. So it is not possible to pass the value of arbitrary fields or even expressions to the parametrized struct. This would have been possible with the previously discussed <typearg>. That can be added later, if needed. ( Wont be too complicated ) * So this is pretty much like the proposal from Ran Benita. changes for V2 of this patch, according to suggestions from Ran Benita: * replace map with list comprehension because map returns an iterator instead of a list from Python 3 on, so it cannot be added to a list anymore. * removed "self" parameter of function additional_params_to_str and accessed the variable additional_params from the outer function directly. changes for V2 of this patch: * adapt to revision 2 of patchset ListInputDevices * style fixes for similar things that Ran Benita has found in my previous patches Message-ID: <54574397.4060000@DemoRecorder.com> Patch-Thread-Subject: [Xcb] parametrized structs implemented Patch-Set: ParametrizedStruct Patch-Number: libxcb 1/1 Patch-Version: V3 Signed-off-by: Christian Linhart <chris@DemoRecorder.com> |
||
|---|---|---|
| doc | ||
| m4 | ||
| man | ||
| src | ||
| tests | ||
| tools | ||
| .autom4te.cfg | ||
| .gitignore | ||
| COPYING | ||
| Makefile.am | ||
| NEWS | ||
| README | ||
| autogen.sh | ||
| check-pc-requires | ||
| configure.ac | ||
| xcb-composite.pc.in | ||
| xcb-damage.pc.in | ||
| xcb-dpms.pc.in | ||
| xcb-dri2.pc.in | ||
| xcb-dri3.pc.in | ||
| xcb-glx.pc.in | ||
| xcb-present.pc.in | ||
| xcb-randr.pc.in | ||
| xcb-record.pc.in | ||
| xcb-render.pc.in | ||
| xcb-res.pc.in | ||
| xcb-screensaver.pc.in | ||
| xcb-shape.pc.in | ||
| xcb-shm.pc.in | ||
| xcb-sync.pc.in | ||
| xcb-xevie.pc.in | ||
| xcb-xf86dri.pc.in | ||
| xcb-xfixes.pc.in | ||
| xcb-xinerama.pc.in | ||
| xcb-xinput.pc.in | ||
| xcb-xkb.pc.in | ||
| xcb-xprint.pc.in | ||
| xcb-xselinux.pc.in | ||
| xcb-xtest.pc.in | ||
| xcb-xv.pc.in | ||
| xcb-xvmc.pc.in | ||
| xcb.pc.in | ||
About libxcb
============
libxcb provides an interface to the X Window System protocol, which
replaces the current Xlib interface. It has several advantages over
Xlib, including:
- size: small, simple library, and lower memory footprint
- latency hiding: batch several requests and wait for the replies later
- direct protocol access: interface and protocol correspond exactly
- proven thread support: transparently access XCB from multiple threads
- easy extension implementation: interfaces auto-generated from XML-XCB
Xlib can also use XCB as a transport layer, allowing software to make
requests and receive responses with both, which eases porting to XCB.
However, client programs, libraries, and toolkits will gain the most
benefit from a native XCB port.
Please report any issues you find to the freedesktop.org bug tracker,
at:
<https://bugs.freedesktop.org/enter_bug.cgi?product=XCB>
Discussion about XCB occurs on the XCB mailing list:
<mailto:xcb at lists.freedesktop.org>
<http://lists.freedesktop.org/mailman/listinfo/xcb>
You can obtain the latest development versions of XCB using GIT.
For anonymous checkouts, use:
git clone git://anongit.freedesktop.org/git/xcb/libxcb
For developers, use:
git clone git+ssh://git.freedesktop.org/git/xcb/libxcb