digitalmars.D.learn - Wrapping C APIs in D functions of same name?
- Rick Mann (3/3) Jan 27 2007 I'm writing interface modules for some C APIs. In a few cases, I need to...
- Tyler Knott (8/12) Jan 27 2007 Yes. Because module imports can be declared as "private" (and are by
- Rick Mann (4/11) Jan 28 2007 Of course; I should've thought of this.
- Chris Nicholson-Sauls (9/24) Jan 28 2007 Exactly this. A function 'int stuff(int)' in module 'bar' in package 'f...
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
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, RickYes. 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)).
Jan 27 2007
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
Rick Mann wrote:Tyler Knott Wrote: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-SaulsYes. 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