DIP 45 - approval discussion
Benjamin Thaut
code at benjamin-thaut.de
Sun Nov 10 22:19:37 PST 2013
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.
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.
More information about the Digitalmars-d
mailing list