DIP 45 - approval discussion

Walter Bright newshound2 at digitalmars.com
Sun Nov 17 21:09:41 PST 2013


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.



More information about the Digitalmars-d mailing list