DIP 45 - approval discussion

Benjamin Thaut code at benjamin-thaut.de
Thu Nov 14 09:25:41 PST 2013


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



More information about the Digitalmars-d mailing list