The paper suggest adding a [[visible]] attribute that could replace the
current compiler-specific ways to export symbols in dynamic-link libraries and
import in modules using them. While a laudable goal, the proposal is
simplistic and won't work.

First, this is simply not the way Visual Studio's compiler works. The paper
says

> It has been publicly mentioned that with the modules feature, having two
> attributes (__declspec(dllexport) and __declspec(dllimport)) is no longer
> the case for MSVC.

But there's no reference to support that assertion. Moreover, even if it is
true, the assertion is that it is not necessary for *Modules*. It makes no
comment about non-module conditions. Modules may be a very interesting
feature, but it's neither accepted into C++17 yet, nor will it be a silver
bullet: DLLs will still exist.

Finally, I argue that having a single attribute generates worse code. I've
asked this of GCC and Binutils developers more than once: the import/export
attribute separation in Visual Studio's compiler (and, by extension, MinGW),
while more cumbersome, allows the compiler to produce better code.

On both the Linux x86 and x86-64 ABI, access to data as well as
materialisation of function pointers can be optimised when the compiler knows
that the target function or variable is in the current module (not imported)
versus when it knows that to be in another module (imported). Without this
information, the compiler is required to assume for all "default" visibility
symbols that it could be in another module, even for those that it is
currently exporting. There are ways to ask the linker to optimise, but the
compiler is often in a better position to produce better code.

Finally, there's the issue that ELF has four visibilities, not just the two
most commonly used in shared libraries. Of special interest is the "protected"
visibility, which exports the symbol to the dynamic symbol table, but prevents
interposition. Aimed with this knowledge, the compiler can assume that the
protected symbol is local and can be addressed via relative to the PC
register. In fact, using visibility("protected") during the compilation of the
library can achieve almos the same benefits as __declspec(dllexport).

So my recommendation to the committee is to not accept this and leave this
problem to the compilers, as importing, exporting and local symbols are
exclusively the provenance of the ABI (with a side note that this feature
allows for violation of ODR).

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/42036164.6u4FZiZuEz%40tjmaciei-mobl1.

.