www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Template Libraries in D

reply 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?
Jan 20 2006
parent reply 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.
Jan 20 2006
parent 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.
Jan 20 2006