Am 14.11.2013 08:36, schrieb Rainer Schuetze:
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.
I actually like this idea. Everytime I actually had to dllexport /
dllimport templates in C++ I knew beforehand which types I need the
template exported for.
But what would should in a case like this:
class WeakReferenced(T)
{
export __gshared WeakReferenced!T[] m_weakTable;
}
Note that the export is not applied to the template directly but instead
to a specific member inside the template.
Should this be an error?
- It's worse for the dllimport case, as data accesses to template
variables will sometimes use the additional indirection, sometimes not.
Why exactly is that? Would that also be the case with the system
proposed by the DIP? The dip never actually uses dllimport, so shouldn't
it just work (tm)?
Kind Regards
Benjamin Thaut
