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.