digitalmars.D.learn - How do I make an extern function?
- Simen kjaeraas (18/18) Jun 28 2010 ////////////////////
- torhu (5/21) Jun 28 2010 Using extern (C) is the only way I've seen this done. I don't know of
- Jonathan M Davis (17/38) Jun 28 2010 Um, extern isn't needed in D. All you need to do is make the function pu...
- BCS (10/30) Jun 28 2010 The issue is that the function called from module a is
- Simen kjaeraas (12/24) Jun 29 2010 I know. I just react to 'extern void foo();' being treated as a
- Steven Schveighoffer (28/50) Jun 29 2010 D symbol names are mangled with their modules, so it is impossible for t...
- BCS (17/27) Jun 29 2010 Several approaches: In addition to interfaces as Steven pointed out, if ...
//////////////////// module a; extern void foo( ); void bar( ) { foo( ); } //////////////////// module b; import std.stdio; void foo( ) { writeln( "Hi!" ); } //////////////////// The above does not work (Error 42: Symbol Undefined _D1a3fooFZv). Adding extern to foo in module b changes nothing. extern( C ) works, but seems like a hack. Better ideas? -- Simen
Jun 28 2010
On 29.06.2010 02:51, Simen kjaeraas wrote://////////////////// module a; extern void foo( ); void bar( ) { foo( ); } //////////////////// module b; import std.stdio; void foo( ) { writeln( "Hi!" ); } //////////////////// The above does not work (Error 42: Symbol Undefined _D1a3fooFZv). Adding extern to foo in module b changes nothing. extern( C ) works, but seems like a hack. Better ideas?Using extern (C) is the only way I've seen this done. I don't know of any way to make the symbols match up otherwise. There's probably some hack that works, but is uglier than the more straightforward solutions. You could always create a b.di file, if that doesn't defeat the purpose.
Jun 28 2010
On Monday, June 28, 2010 17:51:09 Simen kjaeraas wrote://////////////////// module a; extern void foo( ); void bar( ) { foo( ); } //////////////////// module b; import std.stdio; void foo( ) { writeln( "Hi!" ); } //////////////////// The above does not work (Error 42: Symbol Undefined _D1a3fooFZv). Adding extern to foo in module b changes nothing. extern( C ) works, but seems like a hack. Better ideas?Um, extern isn't needed in D. All you need to do is make the function public and then import the module. I would expect this to work: //////////////////// module a; import b; void bar( ) { foo( ); } //////////////////// module b; import std.stdio; void foo( ) { writeln( "Hi!" ); } //////////////////// - Jonathan M Davis
Jun 28 2010
Hello Simen,//////////////////// module a; extern void foo( ); void bar( ) { foo( ); } //////////////////// module b; import std.stdio; void foo( ) { writeln( "Hi!" ); } //////////////////// The above does not work (Error 42: Symbol Undefined _D1a3fooFZv). Adding extern to foo in module b changes nothing. extern( C ) works, but seems like a hack. Better ideas?The issue is that the function called from module a is _D1a3fooFZv where the function defined in module b is _D1b3fooFZv ('a' <-> 'b') so they aren't the same function. extern(C) works because C doesn't mangle names so the function is foo in both cases. You can resolve this by having a a.di file with the extern foo(); in it (DMD has a flag to generate such a file for you). OTOH without knowing what you are doing, I can't tell if this is the correct solution. -- ... <IXOYE><
Jun 28 2010
BCS <none anon.com> wrote:The issue is that the function called from module a is _D1a3fooFZv where the function defined in module b is _D1b3fooFZv ('a' <-> 'b') so they aren't the same function. extern(C) works because C doesn't mangle names so the function is foo in both cases.I know. I just react to 'extern void foo();' being treated as a function that must be in a. I would expect extern to indicate it lies elsewhere in the program.You can resolve this by having a a.di file with the extern foo(); in it (DMD has a flag to generate such a file for you). OTOH without knowing what you are doing, I can't tell if this is the correct solution.I'm trying to create a framework in which the user may provide his own foo( ), so the name of module b is impossible to know. torhu <no spam.invalid> wrote:You could always create a b.di file, if that doesn't defeat the purpose.Jonathan M Davis <jmdavisprog gmail.com> wrote:Um, extern isn't needed in D. All you need to do is make the function public and then import the module.If only life were easy, eh? Module b is user-supplied, so I can't import it. -- Simen
Jun 29 2010
On Tue, 29 Jun 2010 06:24:42 -0400, Simen kjaeraas <simen.kjaras gmail.com> wrote:BCS <none anon.com> wrote:D symbol names are mangled with their modules, so it is impossible for the compiler to know what module it will be in. The fact that it assumes the current module is probably very counterintuitive. Use extern(C) if you do not want mangled names.The issue is that the function called from module a is _D1a3fooFZv where the function defined in module b is _D1b3fooFZv ('a' <-> 'b') so they aren't the same function. extern(C) works because C doesn't mangle names so the function is foo in both cases.I know. I just react to 'extern void foo();' being treated as a function that must be in a. I would expect extern to indicate it lies elsewhere in the program.Then the symbol is impossible to know. D symbols *must* mangle with their module names. Use extern(C) to avoid this. extern(C) functions work just as good as D functions, and for all intents and purposes, are equivalent. Just their names are not mangled, so you cannot have overloads.You can resolve this by having a a.di file with the extern foo(); in it (DMD has a flag to generate such a file for you). OTOH without knowing what you are doing, I can't tell if this is the correct solution.I'm trying to create a framework in which the user may provide his own foo( ), so the name of module b is impossible to know.torhu <no spam.invalid> wrote:Have you thought of using interfaces? This is exactly why interfaces exist (to call functions without knowing who implemented them). What I would do is something like this: interface Foo { void foo1(int x); int foo1(string y); } extern extern(C) Foo getImplementation(); getImplementation().foo1(1); getImplementation().foo1("hi"); Then your client lib has to define their implementation of Foo, and must define one extern (C) function called getImplementation. Or you could make getImplementation a property: extern extern(C) property Foo implementation(); implementation.foo1(1); implementation.foo1("hi"); -SteveYou could always create a b.di file, if that doesn't defeat the purpose.Jonathan M Davis <jmdavisprog gmail.com> wrote:Um, extern isn't needed in D. All you need to do is make the function public and then import the module.If only life were easy, eh? Module b is user-supplied, so I can't import it.
Jun 29 2010
Hello Simen,BCS <none anon.com> wrote:Several approaches: In addition to interfaces as Steven pointed out, if you don't need overloading you can use a function pointer. Also for either option, you could have a global variable that the users code sets from a static this: module a; void function(int) foo; // use foo ------ moduel b; import a; void theFoo(int i) { ... } static this() { foo = &theFoo; } If you want more encapsulation, you could switch to a registration function rather than having people muck around in the dirt. Also, if you have some appropriate object, you can put it there and avoid a global and all it entails. -- ... <IXOYE><You can resolve this by having a a.di file with the extern foo(); in it (DMD has a flag to generate such a file for you). OTOH without knowing what you are doing, I can't tell if this is the correct solution.I'm trying to create a framework in which the user may provide his own foo( ), so the name of module b is impossible to know.
Jun 29 2010