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.
