Problem with coupling shared object symbol visibility with protection

[Benjamin Thaut via Digitalmars-d]

On Tuesday, 27 January 2015 at 22:29:41 UTC, Rainer Schuetze 
wrote:
> I would not mind if we export all symbols on Windows aswell. It 
> doesn't seem to bother a lot of people for the linux version, 
> even though it's unsafer and slower than on Windows (at least 
> that was my experience more than 10 years ago). It might get us 
> a first working version without adding "export" throughout the 
> druntime/phobos source code.

There are multiple reasons why I don't want to simply export 
every symbol:

1) Before I started this implementation I synchronized with 
Martin Nowak regrading hish plans for D shared libraries. It 
turns out that he wants to annotate all of druntime and phobos 
with export asap and use it to control symbol visibility on 
linux. He wants to get away from the "export everything" on linux 
because it hurts performance and prevents some optimizations.
2) Every data symbol that is considered for exporting adds a 
slight performance overhead through a additional indirection, 
even for static builds. That is because the compiler can't know 
if the symbol is imported or not, as export means both import and 
export at the same time. So if the compiler simply assumes that 
all symbols are exported this would add a lot of unnecessary 
overhead even in static builds. (but also in dynamic ones)
3) If we start with export everything on Windows now, it will be 
hared to go back to export only whats annotated.

>
> I don't have a clear favorite, but the second version makes it 
> clearer that visibility and protection are separate issues.
>
> A note on:
> > export public void templateFunc(T)()
>
> I don't think it is well defined what exporting a template is 
> supposed to mean. My guess: whenever an instance of the 
> template is created, its symbols are exported. This could make 
> for a lot of duplicate symbols across multiple DLLs, though.

Obviously its not yet well defined. But we can define it. And you 
are right, it means that all instances are exported. And we need 
that behavior because otherwise you have to spray in -allinst 
everywhere. Believe me I tried.

> Maybe there should be a method of explicitly 
> exporting/importing a template instance from another DLL, e.g.
>
> export alias symbol = templateFunc!int;

I would rather not do that. You don't have to explicitly import 
template instances from static libraries either. We should try to 
keep the behavior of static and dynamic libraries as similar as 
possible. The ideal situation would be that you can simply 
compile something that was a static library into a dynamic one 
without doing any code changes (other then writing export: at the 
beginning of every file)