I'm writing interface modules for some C APIs. In a few cases, I need to pre- and post-process some of the data passed to and from them. I'd like to wrap the methods in "pure" D methods with the same name as the C methods I want to call. Is there any way to do this?

TIA,
Rick

Rick Mann wrote:
> I'm writing interface modules for some C APIs. In a few cases, I need to pre- and post-process some of the data passed to and from them. I'd like to wrap the methods in "pure" D methods with the same name as the C methods I want to call. Is there any way to do this?
> 
> TIA,
> Rick
Yes.  Because module imports can be declared as "private" (and are by default), you can simply write two seperate modules.  One would contain all the extern (C) declarations, and the other containing the D wrappers.  The module with the wrappers would import the module with the externs (privately), and call the extern functions using the fully qualified name of them (e.g. in a module foo.bar with a function func taking (param), you'd call it as foo.bar.func(param)).

Tyler Knott Wrote:

> Yes.  Because module imports can be declared as "private" (and are by default), you can simply write two seperate modules.  One would contain all the extern (C) declarations, and the other containing the D wrappers.  The module with the wrappers would import the module with the externs (privately), and call the extern functions using the fully qualified name of them (e.g. in a module foo.bar with a function func taking (param), you'd call it as foo.bar.func(param)).

Of course; I should've thought of this.

I guess, though, there's no way to do it with a single module, right?

Will the approach above result in link errors when I link my D program against the C library? Or does the D name mangling make the D symbol name different than the C name? Does the D-linkage mangling include the module name?

Rick Mann wrote:
> Tyler Knott Wrote:
> 
>> Yes.  Because module imports can be declared as "private" (and are by default), you can simply write two seperate modules.  One would contain all the extern (C) declarations, and the other containing the D wrappers.  The module with the wrappers would import the module with the externs (privately), and call the extern functions using the fully qualified name of them (e.g. in a module foo.bar with a function func taking (param), you'd call it as foo.bar.func(param)).
> 
> Of course; I should've thought of this.
> 
> I guess, though, there's no way to do it with a single module, right? 
> 
> Will the approach above result in link errors when I link my D program against the C library? Or does the D name mangling make the D symbol name different than the C name? Does the D-linkage mangling include the module name?

Exactly this.  A function 'int stuff(int)' in module 'bar' in package 'foo' will be mangled to something like: S20_D3foo3bar5stuffFiZi

Whereas the extern(C) function 'stuff' would simply be output as 'stuff' with no decoration.  Therefore, the two will not collide during linking.  However, this also means there is no reasonable way to distinguish the C and D functions from each other within source code aside from fully qualified names, hence using the second module to contain the extern declerations.

-- Chris Nicholson-Sauls