http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #24 from Benjamin Thaut <[email protected]> 2013-08-30 00:32:50 PDT --- > I don't think the last point is too critical because exporting data is rarely > done and rather a bad practice. > Also this only applies to the API boundary which shouldn't be a performance > hotspot. The digital mars linker is not capable of doing so. Also as stated on the newsgroup we will most likely not be able to use LTO of the mircosoft linker. Also this will not only affect to API bounadries, it will affect all accesses to global data: __gshared variables, shared variables, and all compiler internal global data symbols like module info, type info, vtables, etc. This is because without knowing what symbols are imported from a DLL we have to add the indirection to all of them. If we decide to use the alias solution we would have to accept the additional level of indirection for all global data accesses and keep in mind that this is most likely going to stay that way for a long time. > Yes, that's what I intend. Doing this manually is important, because exporting > a symbol means commiting to ABI stability, which should be a longterm goal. > Because exported symbols are the known entry points of a library this reopens > the question whether we could use much more inference for non-exported > symbols. I fully agree here. We might still want to provide a -exportall switch for convenience. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
