• Gregor Richards (41/41) May 30 2006 [Apologies if there is already such a thing, but I can't find it]
• Gregor Richards (2/2) May 30 2006 Erm, I posted those aliases backwards ... but you understand what I mean...
• Sean Kelly (20/25) May 30 2006 Frankly, I think this is the wrong approach. Rather than forcing the
• Walter Bright (5/8) May 30 2006 You're right, I went through the same thinking process. I originally was...

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.

Gregor Richards <Richards codu.org> writes:

Erm, I posted those aliases backwards ... but you understand what I mean,
hopefully :)

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

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.