• S. Chancellor (23/23) Jan 20 2006 As it stands currently, pre-compiled libraries of templates are unless i...
• BCS (11/42) Jan 20 2006 Thank you, Thank you, Thank you!!!
• S. Chancellor (28/50) Jan 20 2006 Doubtful, it would still depend on what files you were compiling at the

S. Chancellor <dnewsgr mephit.kicks-ass.org> writes:

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?

BCS <BCS_member pathlink.com> writes:

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.

S. Chancellor<dnewsgr mephit.kicks-ass.org> writes:

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.