Fair enough, thanks for the time.
I found a thin D binding to ncurses, and 'fixed' it to work with D2.
If y'all get this up and running, this code will probably be better than starting from scratch.
In any case, I think that CAPI is exactly the type of thing that D needs going forward.
I really hope that CAPI gets good support.
On 10/16/2011 9:28 PM, Jude Young wrote:This is incorrect. String literals in D are 0 terminated, as in C. C has a convention that strings are 0 terminated, but it isn't part of the core language. In D, you can terminate a string with 0 if you want to, or not.
Please excuse my ignorance,
but several types in D do not currently translate well into C.
For example, strings in D are not '\0' terminated, which breaks with C.
This would fall under attempting to fix the api, which would be beyond the scope of the library.
This is not usually a problem, and it's easy to wrap the function in the
translated header file to automate that particular process.
D access to the C API should be direct, and not include hidden costs like translation layers.
It seems that your proposal would disallow this particular example.
The translation code would have to be somewhere, what is the argument against
allowing it?
C doesn't actually even have a 'string' type.
In my (admittedly ignorant) opinion, it seems that allowing the automatic
translation of D types to C types
would fit very well, otherwise you'll have to add them yourself every time you
wish to call C.