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

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

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

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