DLL symbol identity

[Benjamin Thaut via Digitalmars-d]

> Why did Microsoft go with that approach,

Maybe they didn't know better back then. Historically DLLs 
initially didn't support data symbols at all, only functions 
where supported. For functions its not a problem if they are 
duplicated because usually you don't compare pointers to 
functions a lot. Later they added support for data symbols 
building on what they had. I assume the system that is in place 
now is a result of that.

> why did it work for them
Because C/C++ are not as template heavy as D and you basically 
try to avoid cross dll templates in c++ at all cost when 
developing for windows. Because if you do use templates across 
dll boundaries and you are not super careful you get a lot of 
issues due to duplicate symbols (e.g. static variables existing 
twice etc). MSVC gets around the casting issue by essentially 
doing string comparisons for dynamic casts which comes with a 
significant performance impact. On the other hand you don't use 
dynamic casts in c++ a lot (if you care about performance).

> and why does it not map well to D ?
D uses tons of templates everywhere. Even type information for 
non templated types is generated on demand and stored in comdats 
which can lead to duplicate symbols the same way it does for 
templates. In D the dynamic cast is basically the default and you 
have to force the compiler to not use a dynamic cast if you care 
for performance.


Its not like the linux approach doesn't have issues as well. I 
heard of cases where people put large parts of boost into a 
shared library and the linux loader would take multiple minutes 
to load the shared library into the program. This however is 
mostly due to the fact that on linux all symbols are visible from 
a shared library by default. In later versions of gcc (4+) they 
added a option to make all symbols hidden by default 
(-fvisibility=hidden) and you can make only those visible that 
you need. This then significantly speeds up loading of shared 
libraries because the number of symbols that need to be resolved 
is greatly decreased.

On the other hand the linux approach has a additional advantage I 
didn't mention yet. You can use the LD_PRELOAD feature to 
"inject" shared libraries into processes. E.g. for injecting a 
better malloc library to speed up your favorite program. This is 
not easily possible with the windows approach to shared libraries.