www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Wrapping C APIs in D functions of same name?

reply Rick Mann <rmann-d-lang latencyzero.com> writes:
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
Jan 27 2007
parent reply Tyler Knott <tywebmail mailcity.com> writes:
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

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)).
Jan 27 2007
parent reply Rick Mann <rmann-d-lang latencyzero.com> writes:
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?
Jan 28 2007
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
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
Jan 28 2007