On 10.11.2013 12:38, Benjamin Thaut wrote:
Attached you will find a e-mail conversation about the discussion of DIP
45. I moved the discussion here so everyone can contribute.
Hi,
DIP 45 is waiting for some offical approval / comment so it can be
implemented. It would be great if one of you could look into the topic
and give official approval or improvement suggestions as the DIP has
been in limbo for quite some time now. I'm not willing to start working
on it before there is official approval, because I made bad experiences
with this in the past.
In my opinion the DIP is in a state where further discussion will not
lead to any improvements. The DIP should be implemented to see which
problems arrise during implementation to then discuss how to solve them.
I've also seen a couple of questions to the state of Windows DLL support
and shared libraries on the newsgroup. A working export keyword is
required to actually implement that support on windows.
The DIP: http://wiki.dlang.org/DIP45
The latest discussion on the NG:
http://forum.dlang.org/post/kvhu2c$2ikq$1...@digitalmars.com
Bug associated with the problem:
http://d.puremagic.com/issues/show_bug.cgi?id=9816
Kind Regards
Benjamin Thaut
I think the DIP is very reasonable. Some random comments:
- when building a single object file or library, I would expect that it
won't be torn apart later, so optimizations currently limited to
accesses within the same module by the DIP could be extended to the
modules included in current compilation target.
- a better example where cross-DLL data accesses to globals are needed
is TypeInfo, e.g. when a class info references it's base class or
interfaces.
- I'd be fine with reversing the default for stripping exports from a
library, i.e. replacing "-libexports" with "-stripexports".
- I agree that cross DLL TLS accesses should be possible, though it
might be implemented in a second step. Last time I tried it with C++, it
wasn't supported, but it is probably not missed that much as thread
local data is not as ubiquitous as in D.
- The DIP should state what happens to template instances. Assuming the
definition is marked "export", I guess instances will be dllexport if
they are compiled together with the module that contains the definition.
What will happen if it is instantiated, but the defining module is
merely imported?
Rainer
