www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - How do I make an extern function?

reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
////////////////////
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
next sibling parent torhu <no spam.invalid> writes:
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
prev sibling next sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
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
prev sibling next sibling parent BCS <none anon.com> writes:
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
prev sibling next sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
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
parent BCS <none anon.com> writes:
Hello Simen,

 BCS <none anon.com> wrote:
 

 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.
 

foo( ), so the name of module b is impossible to know.

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><
Jun 29 2010
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 29 Jun 2010 06:24:42 -0400, Simen kjaeraas  
<simen.kjaras gmail.com> wrote:

 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.

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

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

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"); -Steve
Jun 29 2010