I have something like this:

a.d:
char[] myFunction (ushort arg) { ... }

mytest.d:
extern char[] myFunction (ushort arg);

And then I try to compile like this:

dmd -c a.d
dmd mytest a.obj

But I get: "Symbol Undefined _Dmytest_myFunction_FtZAa". Obviously, if I compile both files together, this problem disappears. It seems like dmd makes the linker try to find myFunction under the same module. Is this a bug?

However, this leads me to something else: what if we could do something like

extern char[] a.myFunction (ushort arg);

or

extern (a) char[] myFunction (ushort arg);

or whatever other syntax is thought of. What I mean is a way to specify where the linker should look for the functions. (this could also help me with my getch problem). Then, if for some reasons there were two or more versions of a function, we could specify which one to use in a module. Is this desirable?

-------------------------
Carlos Santander


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.493 / Virus Database: 292 - Release Date: 2003-06-25

"Carlos Santander B." wrote:
> 
> I have something like this:
> 
> a.d:
> char[] myFunction (ushort arg) { ... }
> 
> mytest.d:
> extern char[] myFunction (ushort arg);
> 
> And then I try to compile like this:
> 
> dmd -c a.d
> dmd mytest a.obj
> 
> But I get: "Symbol Undefined _Dmytest_myFunction_FtZAa". Obviously, if I compile both files together, this problem disappears. It seems like dmd makes the linker try to find myFunction under the same module. Is this a bug?
> 
> However, this leads me to something else: what if we could do something like
> 
> extern char[] a.myFunction (ushort arg);
> 
> or
> 
> extern (a) char[] myFunction (ushort arg);
> 
> or whatever other syntax is thought of. What I mean is a way to specify where the linker should look for the functions. (this could also help me with my getch problem). Then, if for some reasons there were two or more versions of a function, we could specify which one to use in a module. Is this desirable?

I think "as a D programmer" you are required to use the import statement instead of the "old C" extern statement. "extern" is dangerous because it introduces a redundancy that can bite you if you change a function without changing all extern references to the function.

Whether this "extern for D module-function" should work anyway I don't know.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

"Helmut Leitner" <leitner@hls.via.at> wrote in message news:3EFBED32.32FF7B84@hls.via.at...
> "Carlos Santander B." wrote:
> > I have something like this:
> > a.d:
> > char[] myFunction (ushort arg) { ... }
> > mytest.d:
> > extern char[] myFunction (ushort arg);
> > And then I try to compile like this:
> > dmd -c a.d
> > dmd mytest a.obj
> >
> > But I get: "Symbol Undefined _Dmytest_myFunction_FtZAa". Obviously, if I compile both files together, this problem disappears. It seems like dmd makes the linker try to find myFunction under the same module. Is this a bug?
> >
> > However, this leads me to something else: what if we could do something
like
> >
> > extern char[] a.myFunction (ushort arg);
> >
> > or
> >
> > extern (a) char[] myFunction (ushort arg);
> >
> > or whatever other syntax is thought of. What I mean is a way to specify where the linker should look for the functions. (this could also help me with my getch problem). Then, if for some reasons there were two or more versions of a function, we could specify which one to use in a module.
Is
> > this desirable?
> I think "as a D programmer" you are required to use the import statement instead of the "old C" extern statement. "extern" is dangerous because it introduces a redundancy that can bite you if you change a function without changing all extern references to the function.

That is correct.

> Whether this "extern for D module-function" should work anyway I don't
know.

No, it shouldn't work. D functions are married to the module they are defined in, the module name forms part of the mangled name of the function. Therefore, you cannot reference a D function in another module without importing that module.

"Helmut Leitner" <leitner@hls.via.at> escribió en el mensaje
news:3EFBED32.32FF7B84@hls.via.at...
|
| I think "as a D programmer" you are required to use the import statement
| instead of the "old C" extern statement. "extern" is dangerous because it
| introduces a redundancy that can bite you if you change a function
| without changing all extern references to the function.
|

Ok, yes, maybe externs are dangerous. But I'm thinking about something else: if I'd like to distribute a class library, or a template library, and I didn't want to release the source code but only the .lib, how would everybody else compile something using my library if they don't have the source code? At least for functions we can always distribute some kind of a header file (or declarations file, whatever name you prefer), but not for classes or templates. Source code must be included too, and I see that as a problem.

That's not the case: I'm not planning to distribute anything, but I'm just trying to look ahead because somebody would like to do so.

-------------------------
Carlos Santander


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.493 / Virus Database: 292 - Release Date: 2003-06-25

"Carlos Santander B." wrote:
> 
> "Helmut Leitner" <leitner@hls.via.at> escribió en el mensaje
> news:3EFBED32.32FF7B84@hls.via.at...
> |
> | I think "as a D programmer" you are required to use the import statement
> | instead of the "old C" extern statement. "extern" is dangerous because it
> | introduces a redundancy that can bite you if you change a function
> | without changing all extern references to the function.
> |
> 
> Ok, yes, maybe externs are dangerous. But I'm thinking about something else: if I'd like to distribute a class library, or a template library, and I didn't want to release the source code but only the .lib, how would everybody else compile something using my library if they don't have the source code? At least for functions we can always distribute some kind of a header file (or declarations file, whatever name you prefer), but not for classes or templates. Source code must be included too, and I see that as a problem.

I think Burtons DIG does this.

But I think the compiler should automatically produce a stripped
  module.dd (or .ds or whatever)
and take it instead of the source unless outdated.

--
Helmut Leitner    leitner@hls.via.at Graz, Austria   www.hls-software.com

"Carlos Santander B." <carlos8294@msn.com> wrote in message news:bdishn$2kbe$1@digitaldaemon.com...
> Ok, yes, maybe externs are dangerous. But I'm thinking about something
else:
> if I'd like to distribute a class library, or a template library, and I didn't want to release the source code but only the .lib, how would everybody else compile something using my library if they don't have the source code? At least for functions we can always distribute some kind of
a
> header file (or declarations file, whatever name you prefer), but not for classes or templates. Source code must be included too, and I see that as
a
> problem.

See phobos/gc.d for an example of how to do this.