DIP 45 - approval discussion

[Walter Bright]

On 11/10/2013 10:19 PM, Benjamin Thaut wrote:
> Am 11.11.2013 05:17, schrieb Walter Bright:
>> On 11/10/2013 1:50 PM, Benjamin Thaut wrote:
>>
>> The compiler would benefit from knowing which modules are from a shared
>> library, and it needs to anyway in order to distinguish between
>> dllimport and dllexport.
>>
>
> Then you didn't understand the DIP correctly. One of the main points of this DIP
> is to provide a implementation of the export attribute that does _not_ require
> the compiler to know anything about, wether certain modules will end up in a DLL
> or not. With the proposed behaviour you could compile a module into an object
> file and then link it both into a DLL and static lirary. Both would just work.
> When using a library the compiler also doesn't have to know if the lirary is
> shared or static. Both will work and it will be decided at link time which path
> is coosen (static or shared). Generally this behaviour makes the export
> attribute easier to use and less error prone.

I do understand that. I just have strong doubts about whether that is the best 
approach or not.


> In an early version of this DIP did involve giving the compiler the information
> which modules end up in an shared library, but it was rejected in the
> discussion. A solution which does not require this information was preferred by
> almost all users taking part in the discussion.
>
>>
>> The trouble is, the proposed solution for exporting TLS variables is to
>> wrap the access in a function that is not inline-able anyway. For
>> performance oriented code, the user would be better off to write his own
>> wrapper, and then hoist the call out of the hot spot, and use a pointer
>> to the TLS variable in the hot spot.
>>
>> As a general rule, if code has a "hot spot" that crosses a DLL boundary,
>> there is going to be performance problems with it regardless. I don't
>> think this is a problem that the language can solve without some effort
>> from the user.
>
> Correct. But the compiler would still be able do other optimizations given the
> function is sligtly bigger then a simple getter.

That's possible, but I suspect much of the potential gains would be lost.