DIP45: fixing the dllimport/dllexport issue

[deadalnix]

On Friday, 30 August 2013 at 08:23:20 UTC, Benjamin Thaut wrote:
> So let me summarize the currently discussed solutions:
>
> 1) Use alias symbols
> Pros:
>  - Better usability (no additional command line parameters 
> needed when compiling / linking against DLLs)
>
> Cons:
>  - Less efficient code for cross DLL function calls (one 
> additional call instruction)
>  - Less efficient code for all accesses to global data, no 
> matter if it will end up in a DLL or not. That means __gshared 
> variables, global shared variables, hidden global data like 
> module info, type info, vtables, etc (one additional level of 
> indirection). It might be possible to avoid this in most cases 
> using link time optimization. But it is unlikely that we can 
> get LTO to work easily.
>  - Additional level of indirection might confuse current 
> debuggers
>

My understanding is that it can be optimized away. Or can it ?

> 2) Use additional command line
> Pros:
>  - More efficient code
>
> Cons:
>  - Additional command line parameters needed when compiling / 
> linking against a DLL. (can be hidden away inside sc.ini for 
> phobos / druntime)