Re: [Swig-devel] Submission of a new language module

[David N. <co...@kl...>]

On 9/27/10 8:31 PM, William S Fulton wrote:
>> Since D supports (C-style) pointers, pointers to primitive types and
>> pointers to functions only having (pointers to) primitive types in
>> their signature are translated to native D pointers by default (any
>> number of indirections, only if there is no other typemap overriding
>> that behavior). […]
>>
> I'm not following 100% and an example might help. Are you saying that
> functions that only have primitive pointers as parameters are handled
> differently to when the function has a mix of pointers and non-pointers?
> So there is a change in marshalling/type handling depending on other
> types in the function?

Okay, let me elaborate a bit. D supports the C ABI and has all C 
primitive types too, so you can directly use C pointers from within D to 
access data. This obviously only works if the data is stored the same on 
a bit level, i.e. there is no additional conversion needed.

If it was only for the quite limited number of primitive types, defining 
the typemaps per hand would certainly be feasible. However, this works 
for an arbitrary number of indirections. So, e.g. if a C function 
returned int***, you could directly use that result in D without any 
conversion code.

Additionally, and this is where defining the typemaps per hand is not 
much of an option anymore, D also has C-style function pointers. For 
example, consider the following C function declaration:

void add_callback(void (* pointer)(char *name), int *was_added);

Using the feature I implemented by providing a hook in the typemap 
lookup process of SWIG before falling back to SWIGTYPE, this is directly 
translated to the corresponding D signature (omitting the extern(C) 
attributes for simplicity):

void add_callback( void function( char* name ), int* was_added );

If there were no default typemaps for these cases, interfacing with C 
code would be a lot more difficult than necessary. Yes, this breaks as 
soon as types wrapped with a proxy class enter the picture, but the D 
module just falls back to a SWIGTYPE_… type wrapper class then. But it 
is surprising how many »plain old C« libraries can be used directly even 
with this restriction in place.

Oh, in theory it would be possible to wrap C structs or C++ POD 
structs/classes as D structs as well (as mentioned above, the whole C 
ABI is supported), providing bit-level compatibility for these too, but 
this is a quite intricate and error-prone process – even more so as 
there is, as far as I know, no other SWIG module which does something 
comparable.

David