[Xcb] Hello xcblist.

[Jamey Sharp]

Thanks for the explanation, Thomas! I have some follow-up questions.

On Thu, Feb 4, 2010 at 10:53 PM, Thomas Heller
<thom.heller at googlemail.com> wrote:
> On Thu, Feb 4, 2010 at 10:15 PM, Barton C Massey <bart at cs.pdx.edu> wrote:
>> What motivated you to write C++ bindings for XCB---what did
>> you find deficient in the existing C binding?
>
> After browsing a little more through xcbs code I disliked several
> things:
>  - all the casting of pointers from one type to another type. I
>    understand that this is common C practice but i believe
>    such things don't belong into a modern C++ Application

Do you have an example of what bothered you? I see these cases:

- Some external API, like struct sockaddr, forces us to cast pointers.
  Nothing to be done about it, or at least C++ doesn't help.

- Internally, we access buffers through pointers of different sizes at
  different times. Using the same pointer type in all cases would
  complicate the code considerably, making it less efficient and harder
  to understand and maintain. Again, I think C++ doesn't help.

- Response types can't be distinguished at compile time, so we cast once
  we've discovered the correct run-time type to use. I agree that this
  is unfortunate, and worse, it leaks into the public API a bit. But I
  don't see a way to fix this using C++ that both is efficient and
  doesn't limit the binding's support for extensions.

>  - through your naming scheme inside of libxcb you implicitly
>    introduce namespaces (with all the prefixes),

Yes, that's the C idiom corresponding to C++'s namespace feature. Why
is that a problem?

>  - you work with lists and iterators.
> ... the lists and the iterators come for free by using the stdlib.

I'm skeptical that you'll get much "for free". :-) The visible API
presents iterators; the internal implementation, in unrelated places,
uses linked lists.

Iterating over the variable-length structures of the X protocol is a
little bit tricky in any language. Certainly you'll get useful
algorithms and such that you can use with the iterators, once you've
wrapped them up in C++-style, but I don't see that the standard library
will help you at all in constructing iterators in the first place.

Yes, the internal implementation of XCB uses linked lists heavily, and
C++ templates mean you can have an inefficient but type-safe generic
list that would abstract away a little bit of XCB's code. Is that what
you meant? I'd rather have the purpose-built list implementations.

The xcb_list.c source file actually dates back to the earliest versions
of XCB, which I wrote not long after my computer science classes
introduced me to C++. For a long time XCB used a single implementation
of linked lists, with plenty of coercions to and from void pointers. It
turned out that the code was simpler and easier to understand once it
was specialized. Today only the _xcb_map code remains, and it's only
semi-generic because I've never gotten around to specializing it for the
one place it's used.

> After these few considerations I decided to implement the protocol
> from scratch. Since you provide the descriptions in the nice xml
> documents, this shouldn't be so hard (this was my initial guess). Now
> it is 4 months later and i still don't have good results :)

The relatively tiny bit of code that's in XCB is solving some remarkably
intricate problems. :-)

> Nevertheless I believe by providing a completely native language
> binding (not just a wrapper) you can use the specific features of your
> language (which you believe are superior to C, otherwise you wouldn't
> program in that language ;)) and don't have to care about the legacy
> code you try to wrap.

It seems to me that any language binding should enable use of that
language's features even if it is wrapping code written in another
language. Sometimes that means improving XCB, as in the recent
discussion about adding xcb_discard_reply for the benefit of
garbage-collected languages, among other reasons.

More importantly: as Bart wrote, wrapping XCB's C API "is generally
preferred; it allows target-language applications to freely mix FFI
calls to libraries that indirectly talk to XCB with direct XCB calls."
Put another way, anyone wanting to use your pure C++ library has to
completely re-write their program and any X-related libraries it uses,
such as Xlib, cairo, Gtk+, Qt...

Frankly, I suspect that would be a death sentence for any C++ binding.
Programmers in some other languages are used to doing that kind of
rewrite all the time, but C++ programmers expect to be able to drop any
existing C library into their projects.

> On advantage my parsers has over the python generator: It can detect
> an error if the given xml doesn't fulfill the "xcb language" defined
> in xcb.xsd.

I like schema validation. Which is why the 'make check' target in
xcb-proto validates everything there. Validating in each consumer isn't
a bad idea at all, but isn't really necessary either.

Good luck on your exams!

Jamey