>>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!
>>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!
Ubuntu Desktop
GCC/G++
Geany (for quick projects)
Anjuta (for larger things)
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.
Last edited by CornedBee; 12-06-2008 at 11:51 AM.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Seems to me like you're trying to re-implement the export keyword.
But since it already exists...
Originally Posted by Adak
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?
Ubuntu Desktop
GCC/G++
Geany (for quick projects)
Anjuta (for larger things)
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.
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
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.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.
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Yes, how templates are seen in the eyes of the compiler is beyond me, but the basic idea is this.
So can you enlight us then?
Vanity of vanities, saith the Preacher, vanity of vanities; all is vanity.
What profit hath a man of all his labour which he taketh under the sun?
All the rivers run into the sea; yet the sea is not full; unto the place from whence the rivers come, thither they return again.
For in much wisdom is much grief: and he that increaseth knowledge increaseth sorrow.
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.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
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
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
