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.
