www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Suggestion: std.ctypes

reply Gregor Richards <Richards codu.org> writes:
[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.  It could look, for example, like:

version (X86) {
alias c_long_long_signed_int_t long;
alias c_long_long_unsigned_int_t ulong;
alias c_long_long_int_t long;

alias c_long_signed_int_t int;
alias c_long_unsigned_int_t uint;
alias c_long_int_t int;

alias c_signed_int_t int;
alias c_unsigned_int_t uint;
alias c_int_t int;

// etc, etc
} else version (X86_64) {
alias c_long_long_signed_int_t long;
alias c_long_long_unsigned_int_t ulong;
alias c_long_long_int_t long;

alias c_long_signed_int_t long;
alias c_long_unsigned_int_t ulong;
alias c_long_int_t long;

alias c_signed_int_t int;
alias c_unsigned_int_t uint;
alias c_int_t int;

// etc, etc
} else version (IA64) {
alias c_long_long_signed_int_t long;
alias c_long_long_unsigned_int_t ulong;
alias c_long_long_int_t long;

alias c_long_signed_int_t long;
alias c_long_unsigned_int_t ulong;
alias c_long_int_t long;

alias c_signed_int_t long;
alias c_unsigned_int_t ulong;
alias c_int_t long;

// etc, etc
}

(I'm probably misremembering most of those sizes, but you get the idea)

This would make it a lot easier to make bindings that were non-system-specific,
since they could simply import std.ctypes and then use c_int_t, etc.
May 30 2006
next sibling parent Gregor Richards <Richards codu.org> writes:
Erm, I posted those aliases backwards ... but you understand what I mean,
hopefully :)
May 30 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
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
May 30 2006
parent Walter Bright <newshound digitalmars.com> writes:
Sean Kelly wrote:
 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.

You're right, I went through the same thinking process. I originally was going to do an std.ctypes, but the result just looked terrible, and frankly, the problems with just translating the types directly into D types work out tolerably well enough.
May 30 2006