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 Mon, Oct 17, 2011 at 12:55 AM, Walter Bright <newshou...@digitalmars.com>wrote: > On 10/16/2011 9:28 PM, Jude Young wrote: > >> 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 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. > > > This is not usually a problem, and it's easy to wrap the function in the >> translated header file to automate that particular process. >> > > This would fall under attempting to fix the api, which would be beyond the > scope of the library. > > > > 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? >> > > D access to the C API should be direct, and not include hidden costs like > translation layers. > > > > 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. >> > > C doesn't actually even have a 'string' type. >