DIP 45 - approval discussion

[Rainer Schuetze]

On 13.11.2013 09:27, Benjamin Thaut wrote:
> Am 13.11.2013 08:31, schrieb Rainer Schuetze:
>>
>> - 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
>
> That is a very good point I also thought about. But because I'm not
> familiar with how exactly template instanciation works I can't really
> provide a solution for that.
>
> Does Walters recent template instanciation optimization also take into
> account template instaces of templates that are defined outside of the
> module that contains the template definition? I think the behaviour of
> exported template should mainly satisfy the needs of this optimization.


As far as I understand, the optimization avoids generating code for 
template instances only _created_ (not defined) by imported modules, 
e.g. when needed for semantic analysis inside the imported module, but 
never actually referenced by generated code by the root modules.

[OT: The problem of the current implementation is the detection of 
"only" in that definition, it fails too often leading to linker errors 
and the addition of that terrible -allinst switch. I had to disable the 
optimization for me before addition of that switch.]

With respect to export I guess the optimization doesn't change much as 
multiple instances of the same template instance still can be found in 
different object files (maybe even less predictable).

To avoid the trouble with templates, here is an idea for discussion:

- templates definitions by themselves are never dllexport/dllimport

- template instances are dllexport/dllimport with the proposed semantics 
of normal functions/variables if they are explicitely declared as 
"export" by an alias statement, e.g.

   export alias templ!int exported_tmpl_int;

- implicitely created template instances don't create dllexport 
versions, and use dllimport semantics if the declaration above is found 
in an import.

This would make it very explicit which module dllexports the template 
instance symbols. It is a bit like using typedef in C++ to ensure 
template instantiation.

One problem that might appear is that there are some conflicts if some 
modules import the "export alias" declaration, and some do not:

- In the dllexport case, it means that there are different COMDATs for 
the code and data of the template and it is undefined which one is 
chosen. (For Win64 COFF the exporting of the symbol is a separate 
directive, so it shouldn't be a problem, but I don't know for other 
object file formats.)

- It's worse for the dllimport case, as data accesses to template 
variables will sometimes use the additional indirection, sometimes not.