>>What would #thedr do?
In my feable mind, it would tell the compiler that it's a template so do the behind the scenes compiler magic and allow it to be treated like any non-template header file! LOl!
Printable View
>>What would #thedr do?
In my feable mind, it would tell the compiler that it's a template so do the behind the scenes compiler magic and allow it to be treated like any non-template header file! LOl!
There's nothing special about a header file that contains a template. Header files are just text files included verbatim by the preprocessor. The template engine never knows whether the stuff it sees comes from a header, from a main source, from a precompiled header, is generated by macros, generated using a compiler-specific special extension, or inserted randomly just to mix things up a bit.
Seems to me like you're trying to re-implement the export keyword.
But since it already exists...
This is why I said it was above my head...
But I thought the way the .o file was generated was somehow different for templates than other object files? Is this where the complication is involved?
EDIT: Complication being implementing the "export" keyword?
No. The fact that you think a .o file is an integral part of compiling C++ shows the actual problem. The traditional C compilation model is simply inappropriate for exported templates. Implementations that use tricks to still integrate in this system are inefficient.
If there was a C++ implementation that completely changed the compilation model, it could perhaps implement exported templates efficiently and easily. Currently, there is no such implementation. One of the big obstacles in creating it would be that it just doesn't play nice with current project management tools.
See, the problem is that a .o file does not contain templates. When the object file is generated, all templates must have already been instantiated. Thus, the compiler must have the template definition before generating the object file.
While I do not fully understand the export keyword (why it is so complicated), I can say that templates are complex, but nothing special.
The compiler just copies the code, replaced template parameters and thus embeds the code into the file which includes and uses the template. Basically.
Uh huh. I suggest you first study how templates are implemented before saying such a thing. Because I'm helping in an implementation right now, and believe me, you're completely wrong.Quote:
I can say that templates are complex, but nothing special.
The compiler just copies the code, replaced template parameters and thus embeds the code into the file which includes and uses the template. Basically.
Yes, how templates are seen in the eyes of the compiler is beyond me, but the basic idea is this.
The problem is that object files contain actual machine code that implements the functions within the associated source, including the code to call functions outside that object file.
With templates, the declaration itself cannot be turned to machine code without an instance of that template. Only with both the declaration and the instance does the compiler have enough information to generate the object code. So the common implementation is that template code is generated for each instance in each object file it is used. Then duplicates have to be removed during linking.
Extern templates could be implemented by having special standin flags instead of the code for the template. It would then have to generate the real code when linking. But then you can't optimize the non template code in the same step as the rest of the code. Furthermore since the template code is not saved in an separate file with known dependencies, this kind of implementation would require the compiler to generate the template code every time the project was compiled, even if something unrelated was changed.
Without going into the fundamental design of the Clang compiler and then explaining how templates requires changes throughout everything? Not really. But if you want to learn about it yourself, then study how Clang works (it's very straight-forward) and then read the recently contributed code by Doug Gregor for handling templates:
http://lists.cs.uiuc.edu/pipermail/c...01/009984.html
http://lists.cs.uiuc.edu/pipermail/c...01/009985.html