As it stands currently, pre-compiled libraries of templates are unless if they do not contain the instances of the template you specifically need.  And also if the source file for the template is imported but not specified to the compiler at the same time as your main code, a template instance will not be generated in your object file.  For example, if you import mintl.all but don't include all the mintl/*.d files on your command line, you won't end up with a template instance in your object files.  Also, if you DO specify them, the instances are generated in the object files for their respective modules (not the modules they were instantiated in.)

I have posted to D.bugs before about this, but I can only think of a few ways to resolve this problem, and one significantly changes how templates operaterate this this time.

The fixes are A:
Put the template object code in the object file for module instantiating the
template. Leave the symbols the same and rely on telling the linker to ignore
duplicate symbols.

B:
Instantiate the objects for each module, put the code in their object files, and
mangle the instance so they're different.  However, this changes the behavior
such that templates are per module, and not per application.  This is good in my
opinion, as now you don't have different modules affecting each other through
the use of the same template instance.


Opinions?

S. Chancellor wrote:
> As it stands currently, pre-compiled libraries of templates are unless if they
> do not contain the instances of the template you specifically need.  And also if
> the source file for the template is imported but not specified to the compiler
> at the same time as your main code, a template instance will not be generated in
> your object file.  For example, if you import mintl.all but don't include all
> the mintl/*.d files on your command line, you won't end up with a template
> instance in your object files.  Also, if you DO specify them, the instances are
> generated in the object files for their respective modules (not the modules they
> were instantiated in.)
> 
> I have posted to D.bugs before about this, but I can only think of a few ways to
> resolve this problem, and one significantly changes how templates operaterate
> this this time.
> 
> The fixes are A:
> Put the template object code in the object file for module instantiating the
> template. Leave the symbols the same and rely on telling the linker to ignore
> duplicate symbols.
> 
> B:
> Instantiate the objects for each module, put the code in their object files, and
> mangle the instance so they're different.  However, this changes the behavior
> such that templates are per module, and not per application.  This is good in my
> opinion, as now you don't have different modules affecting each other through
> the use of the same template instance.
> 
> 
> Opinions?
> 
> 
> 


Thank you, Thank you, Thank you!!!
This just told me what a bunch of bugs were caused by!!


As to what you were saying, this NEEDS a fix. As to "A", would this work with out generating duplicate symbol errors?

another posibility

C:
Allow for explicet instancing without calling. When the template module is compiled, include a list of types to instance it for. The list could be another file (implementation specific) generated by the compiler when ever it instances a template that it isn't generating code for.

BCS <BCS_member@pathlink.com> wrote:
>S. Chancellor wrote:
>> the mintl/*.d files on your command line, you won't end up with a template were instantiated in.)
>> 
>> this this time.
>> 
>> The fixes are A:
>> Put the template object code in the object file for module instantiating the
>> duplicate symbols.
>> 
>> B:
>> the use of the same template instance.
>> 
>> Opinions?
>
>Thank you, Thank you, Thank you!!!
>This just told me what a bunch of bugs were caused by!!
>
>
>As to what you were saying, this NEEDS a fix. As to "A", would this work with out generating duplicate symbol errors?
>
>another posibility

Doubtful, it would still depend on what files you were compiling at the
same time.  The compiler has no idea which object file to put the
templates into if you're compiling each module one at a time.  (dmd -c foo.d;
dmd -c bar.d;  gcc foo.o bar.o -o Bar -lphobos etc  It needs to put the
templates in both object files, so you need to tell ld "z muldefs") In
my opinion templates should be per module since they can contain state
information, and modules don't necessarily know about each other.  For
example:
templateFoo.d:  template Bar(T) { T var };
a.d:  alias Bar(int) Bob; Bob.var = 2;
b.d:  alias Bar(int) Foo;  writefln(Foo.var);

This would currently print two (depending on execution order.)  This
could lead to nasty bugs.
>
>C:
>Allow for explicet instancing without calling. When the template module is
>a template that it isn't generating code for.

I think that this is already the case I'm fairly sure as mintl includes
support for integers and some other basic types when compiled as a
library.  I think creating an alias will do the trick, but this is rather
ugly as you still need to know what templates you need before you compile
the library.   Also, if you have your own types (which i'm having
problems with.)  Like a Foobar class, you need to import your Foobar class into
mintl so dmd can know about it when you goto compile.   It also doesn't
fix the fact that templates are still project global.
I'm rather curious as to how C++ resolves these problems, since it
should theoretically run into the same things.  I need to do some
investigative work I guess.
-S.

-- 
Email works.