www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - module scope and the mysterious main function

reply Jaap Geurts <Jaap_member pathlink.com> writes:
I've been trying the following but without luck.

I have two files fileA.d and fileB.d. FileB wants to call a function in fileB
without actually including fileB. I want it to resolve the function at link
time. However this doesn't work as files are modules and, even without a module
declaration, files introduce a scope therefore the name mangling scheme prevents
linking the exe.
Ex.:

----
filea.d

import std.stream;

int MyMain(char[][] args)
{
foreach(char[] str; args)
stderr.writefln(str);
return 0;
}

----
fileb.d


int MyMain(char[][] args);

int main(char[][] args)
{
MyMain(args);
return 0;
}

----
End Ex.

Strangely enough the phobos library does this in exactly the same way calling
the user supplied main function by just declaring a forward declaration for
main.
See src/phobos/internal/dmain2.d

Is the dmd compiler cheating here? And ignoring the module scope whenever it
sees the function main as a forward decl?

Thanks, Jaap
Sep 22 2004
parent reply Ben Hinkle <bhinkle4 juno.com> writes:
Jaap Geurts wrote:

 I've been trying the following but without luck.
 
 I have two files fileA.d and fileB.d. FileB wants to call a function in
 fileB without actually including fileB. I want it to resolve the function
 at link time. However this doesn't work as files are modules and, even
 without a module declaration, files introduce a scope therefore the name
 mangling scheme prevents linking the exe.
 Ex.:
 
 ----
 filea.d
 
 import std.stream;
 
 int MyMain(char[][] args)
 {
 foreach(char[] str; args)
 stderr.writefln(str);
 return 0;
 }
 
 ----
 fileb.d
 
 
 int MyMain(char[][] args);
 
 int main(char[][] args)
 {
 MyMain(args);
 return 0;
 }
 
 ----
 End Ex.
 
 Strangely enough the phobos library does this in exactly the same way
 calling the user supplied main function by just declaring a forward
 declaration for main.
 See src/phobos/internal/dmain2.d
 
 Is the dmd compiler cheating here? And ignoring the module scope whenever
 it sees the function main as a forward decl?
 
 Thanks, Jaap

extern (C) will prevent the name mangling. Another approach is to have two directory trees for the two fileB files. -Ben
Sep 22 2004
parent "Jaap Geurts" <jaapsen hotmail.com> writes:
"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:cirqda$2dqe$1 digitaldaemon.com...

 Strangely enough the phobos library does this in exactly the same way
 calling the user supplied main function by just declaring a forward
 declaration for main.
 See src/phobos/internal/dmain2.d

 Is the dmd compiler cheating here? And ignoring the module scope


 it sees the function main as a forward decl?

 Thanks, Jaap

extern (C) will prevent the name mangling. Another approach is to have two directory trees for the two fileB files. -Ben

Thanks, Ben But it doesn't quite solve my problem. I've tried the extern (C) but that doesn't work either as it will insert an underscore in front of the name of the external function. And so it will not find the MyMain function. (which I want to be linked as a normal D function). I'd just like to pull the same trick that D is doing. The phobos library calls a D user function(in this case int main(char[][]) in a d module using normal D extern semantics, which is what phobos does. What I actually want to do is handle the troublesome startup code for win32 (the winmain() function) and the linux gtk startup code (gtk_init(int*argc, char***argv). The library should handle the init stuff and the user should be able to just define a MyToolKitMain(char[][] args) function. The phobos library attempts to do the same by transforming the c-style argv list into a D usable args[][]. PS I made a mistake in typing the file names. Actually: I have two files fileA.d and fileB.d. FileB wants to call a function in
 fileA without actually including fileA.


Regards, Jaap
Sep 22 2004