Maybe Deimos (the GitHub presence) could use a dry piece of text that explains how to convert a header. I have just had the need for xcb for example, but no idea how a good header translation is supposed to look like, if all files need to be converted already on the first go and other questions, like if all functions should be marked nothrow for example.

Also it looks like a long on Windows is 32-bit while on Linux it depends on the machine word size and libraries like xcb use "architecture dependent includes" for whatever that means in praxis.

There was even a "Variant" struct that gets additional fields, if the system compiler supports 64-bit ints. This can get ugly really fast and I just went with the comment that said that all interesting compilers support some kind of 64-bit int.

So my impression is that currently only people with a
good background of C on multiple platforms can reliably create
Deimos bindings, unless they share their insights, possibly as
a link from GitHub/Deimos to the Wiki on dlang.org.
("Aldacron"'s blog post is a great start, but I'm looking for
something extendable and collaborative.)

I just imagined if I wrote DBus bindings and someone else wrote XCB bindings, we can share and benefit both. Also Deimos is ideal to be imported as Git sub-modules in other projects. A native D GUI library needs that stuff as well in the long term.

-- 
Marco

On 2013-01-31 21:42, Marco Leise wrote:
> Maybe Deimos (the GitHub presence) could use a dry piece of
> text that explains how to convert a header. I have just had
> the need for xcb for example, but no idea how a good header
> translation is supposed to look like, if all files need to be
> converted already on the first go and other questions, like if
> all functions should be marked nothrow for example.

There's a tool, DStep, that can automatically translate C headers to D modules. It will require some manual adjustments, like adding imports:

https://github.com/jacob-carlborg/dstep

These contain some info about porting a C header to a D module:

http://dlang.org/interfaceToC.html
http://dlang.org/htod.html

There's also a series of blog post about porting creating bindings to C libraries, which I cannot find right now.

> Also it looks like a long on Windows is 32-bit while on Linux
> it depends on the machine word size and libraries like xcb use
> "architecture dependent includes" for whatever that means in
> praxis.

The size of "long" depends on what data model is used. To simplify, on Windows, "long" is always 32bit. On the rest of the platforms "long" is 32 bit when compiling for a 32bit platform and 64 bit when compiling for a 64bit platform.

To be more precise:

http://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models

-- 
/Jacob Carlborg

On Thursday, 31 January 2013 at 20:42:47 UTC, Marco Leise wrote:
> Maybe Deimos (the GitHub presence) could use a dry piece of
> text that explains how to convert a header. I have just had
> the need for xcb for example, but no idea how a good header
> translation is supposed to look like, if all files need to be
> converted already on the first go and other questions, like if
> all functions should be marked nothrow for example.

We should probably start a wiki page.

Regarding nothrow: I'm not really sure if this is officially supported, but at least on linux with dwarf exceptions you can throw exceptions between language boundaries. So a C function might call a extern(C) callback function implemented in D which might throw. In those cases C functions shouldn't be nothrow. In 99% of all cases C functions don't call callbacks and therefore can be nothrow. Deimos does not enforce any rules though. (I think there was a discussion that D doesn't officially support throwing exceptions across language boundaries. In that case you could mark all C fuctions as nothrow, but you'd have to make sure that all callback functions passed to C are nothrow as well.)

>
> Also it looks like a long on Windows is 32-bit while on Linux
> it depends on the machine word size and libraries like xcb use
> "architecture dependent includes" for whatever that means in
> praxis.

You can use core.stdc.config's c_long and c_ulong. What's more problematic is that we'd also need a c_int and c_short. But for the currently supported architectures it's not necessary.

If you need types like int8_t we have core.stdc.stdint. In general if a c binding for your type declarations exists, just use that. If your c types are defined with some weird proprocessor stuff, but the intention is that they always have a fixed size there's a simple solution: you can just implement them as aliases to the D type with the same type and forget about the C preprocessor crap.

>
> There was even a "Variant" struct that gets additional fields,
> if the system compiler supports 64-bit ints. This can get ugly
> really fast and I just went with the comment that said that
> all interesting compilers support some kind of 64-bit int.

You can't know from D if the C comiler supports 64bit integers, so there's nothing you can do. A nice solution would be to use something like version(cHasNo64Int) so users of the binding can still manually force that mode by setting the version.

>
> So my impression is that currently only people with a
> good background of C on multiple platforms can reliably create
> Deimos bindings, unless they share their insights, possibly as
> a link from GitHub/Deimos to the Wiki on dlang.org.
> ("Aldacron"'s blog post is a great start, but I'm looking for
> something extendable and collaborative.)

Yep, that should really be done. Writing bindings for complex C libraries can require some C knowlege though (e.g. when you have to convert weird macros or strange C array syntax or function pointer syntax).

>
> I just imagined if I wrote DBus bindings and someone else
> wrote XCB bindings, we can share and benefit both. Also Deimos
> is ideal to be imported as Git sub-modules in other projects.
> A native D GUI library needs that stuff as well in the long
> term.