• 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...

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

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

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)).

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?

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