www.digitalmars.com         C & C++   DMDScript  

D - bug: declaring externs

reply "Carlos Santander B." <carlos8294 msn.com> writes:
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
Jun 26 2003
parent reply Helmut Leitner <leitner hls.via.at> writes:
"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
Jun 27 2003
next sibling parent "Walter" <walter digitalmars.com> writes:
"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


 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.


 this desirable?

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

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.
Jun 27 2003
prev sibling parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
"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
Jun 27 2003
next sibling parent Helmut Leitner <helmut.leitner chello.at> writes:
"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
Jun 27 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"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

 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

 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

 problem.

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