On 11/15/2013 7:31 AM, Benjamin Thaut wrote:
Am 15/11/2013 08:27, schrieb Walter Bright:
On 11/14/2013 3:37 AM, Benjamin Thaut wrote:
Am 14.11.2013 11:28, schrieb Walter Bright:
On 11/12/2013 2:23 PM, Martin Nowak wrote:
One possibility is modules listed on the command line are regarded as
export==dllexport, and other modules as export==dllimport.
This of course means that functions may wind up going through the
dllimport indirection even for calling functions in the same dll, but it
should work.
That doesns't work for the case where a dll "A" uses a dll "B".
In that case export has to mean "dllexport" for all modules of A but
"dllimport"
for all modules of B.
I don't follow. If you're compiling A, you're specifying A modules on
the command line, and those will regard the B modules as dllimport.
Ok now I understand what you suggest. So basically you want to do the exact same
as DIP 45 just giving the compiler parameter a different name.
But you still didn't give a solution for the problem that the compiler does not
know which modules are part of a shared library, which are part of a static
library and which are part of the exeuctable.
I thought this did cover it. "export" in imported modules that are not listed on
the compiler command line is regarded as "dllimport". "export" in modules listed
on the commmand line is regarded as "dllexport".
And please also consider single file compilation.
And yes, this would mean that a function may wind up calling a function in its
own dll through the dll import thunk -- however -- this thunk is often provided
by the import library, and so wouldn't be there for intra-dll calls.
