On Fri, Jan 22, 2010 at 2:24 AM, Ian Lance Taylor <i...@google.com> wrote: > Timothy Madden <terminato...@gmail.com> writes: > >> Is there any progress or start yet in implemententing export for C++ >> templates ? > > Not to my knowledge. > > The C++0x standards committee considered deprecating export for C++0x, > but I think they have decided to retain it for now. > > >> Why is everybody such not interested in this ? It would be such a >> great feature, especially for >> a leading C++ implementation like gcc ... > > Why would it be useful? What advantage does it provide? > > >> Why is it so hard to store template definitions (and the set of >> symbols visible to them) in an >> object file, probably as a representation of the parsed template source tree >> ? > > I recommend reading "Why We Can't Afford Export." This link may work > for you: > > http://docs.google.com/viewer?a=v&q=cache:lmlZ1p7te3gJ:www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf+why+we+can't+afford+export+sutter&hl=en&gl=us&pid=bl&srcid=ADGEESgDdiuh8WxBHeWHGfnK_iJXXYj0XCWOwfnHQuja8Ihd5567rnFyRsF13uY-HN9NbjYJpwMsUo8VQNx5_ffYSiOfOMeIfKMW-d8s57IMr8B8vUN3UfpXLXVtlLd1C8UiUNNe-i7t&sig=AHIEtbQo42iDSyaR0-I4hQ1bHFV3WTeYfA > > or search for the PDF. > > Note in particular that namespace issues are hideously complex with > export. Thanks to two-phase name lookup, the meaning of a template > depends on the environment in which it is defined. That means that in > order to correctly instantiate an exported template, the export file > must contain not only the template definition, but the definition of > all names mentioned in the template definition, recursively. > > As far as I know, exactly one compiler implements export, and nobody > uses it.
It's because it is not implemented yet that it is not used ... :) Even if I would buy Comeau I would not write code that I know will not compile with any other compiler. Many books though teach how to use a #define to turn your template code into export-ready templates, even if export is not widely available. Actually lots of books and articles talk about export. I have seen that paper in the link, N1426, and I find it to be biased against export ... Everyone will admit to the technical challenges when implementing export. Template code is not object code. It is something else, it is another level, another way of doing things... This is why templates in C++ are so great. For that the compiler has to adapt, there is a new step required in the compilation process, for template instantiation. It is like there are now two levels of compilation: for templates and for object code ... So yes, there would be quite some work for it. The requirement to store symbol table entries when generating pre-compiled templates is as true as it can be. Such an idea is known for quite some time: it is what a precompiled header does: it stores the symbols table. Or at least there are certain similarities or a common approach or point of view. Is this such a problem ? The export keyword is there in the standard with some purpose: it allows the programmer to separate the template definition from the declaration. Its benefits are organised and clear code (and template code) for end-users of the language. It allows anyone to use the template without knowledge of how it is implemented and where it is implemented. It is like in object code one can use external functions and variables without knowledge of where do they come from and how do they work. You just have the declarations and you can use them, templates or not. Many people will say now that it is not the same, that it can not be the same because template code is not like object code, it goes by different rules. Well then I will have to say it loud and clear, that for the end-user's view of things, yes it is ! For them it is the same thing, this is what export does! And it is the end users that matter, it is them the compiler is made for, right ? The differences that still exist (rightfully so, for technical reasons) are ... not important. Someone on that long thread on comp.lang.c++.moderated about 'export' has put things in a very clear light, 6 years ago, when asked what is export so good for: Imagine for a moment that C++ had no one-definition-rule problems, and that it /required/ you to have the body of each and every function you use (call or take address) included in every translation unit ! Imagine you would have to always include the function definition of all functions you call in a .cc file, and the functions that are called by them. How would that be ? Now imagine that this happened because compiler implementers decided it is a real lot of work to devise something like a linker that would link function definitions with references at some point after compilation... I know it is actually possible anyway to write programmes even so, I know that if you insist enough you could write programmes by including all function definitions everywhere, but I bet you 1 dollar that you would not like it ... that you would prefer a new step in the compilation process instead, or some two-levels compilation model. Using export with templates there is also the issue that with two phase lookup users are at risk of getting unexpected behaviour from the templates the use. Although a theoretical problem in all respects, that should be dealt with somehow, this in practice is not at all as big a risk as some people want to make it, and there are ways to help it ... Two other potential uses people might see or think that they see for export, code hiding and improved compilation speed, are only auxiliary, if at all, and much to controversial. I would only say that with export, a library vendor would actually ship files that end with .o and .obj, instead of .cc, and even if such files contain the parse tree of template definitions, they are no longer called "source files". And there is another interesting point with export: once the compiler gets all object files in a program, on the command line, in order to instantiate templates from the pre-compiled definitions, many people might be interested in other things like whole program optimisations that could be done at that time, even if not related to exported templates. Thank you, Timothy Madden
