Suggestion: std.ctypes

[Sean Kelly]

Gregor Richards wrote:
> [Apologies if there is already such a thing, but I can't find it]
> 
> I think it would help both htod and bcd.gen quite a bit if there was a
> std.ctypes, with aliases for all of the system-specific C types to the
> non-system-specific D types.

Frankly, I think this is the wrong approach.  Rather than forcing the 
user to employ special typedefs and such to interface with C routines, 
I'd much rather build a thin wrapper around the C library functions and 
let overloading sort out the proper routine to call.  Sadly, there's no 
way to do this and preserve the original function names, even though the 
mangled names wouldn't actually collide.

By the way, I don't think the situation is as bad as you make it out to 
be.  The only C data types that change widths between popular 
platforms/architectures are long and wchar_t.  And wchar_t is an 
established public symbol, so that really only leaves long as a common 
issue.  Best yet, there are only a handful of C routines that have a 
long parameter, so shouldn't be a huge problem in practice.  In the C 
headers I created for Ares, I've defined 'c_long' and 'c_ulong' aliases 
for this purpose:

http://svn.dsource.org/projects/ares/trunk/src/ares/std/c/config.d

All C declarations in the Ares C99 and Posix headers use c_long 
(excepting maybe some of the darwin blocks, as I didn't write those), so 
adding version logic for Unix64 platforms should be quite simple.


Sean