Any hopes for export ?
in [C++]
|
Prev: Is there any standard/guarantees for exception safety in STL operations?
Next: Does ternary conditional operator bind the order of evaluation?
From: Walter Bright on 26 Jul 2010 13:30 Peter C. Chapin wrote: > In any event, separate compilation of > generic (template) bodies *is* useful and if it worked well in C++ I > would definitely be using it. I haven't asked my compiler vendor to > provide the feature because I know it's pretty much hopeless. Of course > that allows compiler vendors to claim that there's a lack of customer > interest in this matter. It's definitely a chicken-and-egg thing, it > seems to me. The chicken-and-egg issue cannot be much of the story, as it hasn't appeared as a problem preventing vendors from being first to implement other new C++ features. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Timothy Madden on 26 Jul 2010 23:42 Peter C. Chapin wrote: [...] > > [...] In any event, separate compilation of > generic (template) bodies *is* useful and if it worked well in C++ I > would definitely be using it. I haven't asked my compiler vendor to > provide the feature because I know it's pretty much hopeless. Of course > that allows compiler vendors to claim that there's a lack of customer > interest in this matter. It's definitely a chicken-and-egg thing, it > seems to me. It is a useful feature. Separating declaration from implementation is good practice that all programmers should follow. It is this status of just good practice (and not a hard requirement) that makes it feel it is not important and that there is not a demand for it. Thank you, Timothy Madden -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Timothy Madden on 26 Jul 2010 23:42 Dragan Milenkovic wrote: > On 07/25/2010 05:18 PM, Timothy Madden wrote: > [snip] >> I guess this step is also what you are thinking about ("instantiate >> templates at link-time"). To be frank I find all these very >> interesting and I am surprised people are so much against export. > > It may be interesting, but don't you agree that it is > quite a bit messy? I agree it is avantgarde, as a new feature is ! :) The "messy" plan would be: 1. The compiler gets all object files. 2. For each object file that uses exported templates: - Load the symbol table as it was at the end of the translation unit (similar to loading a pre-compiled header) - List templates being used. For each instantiation: - Search object files and find the template definition (result can be cached) - If the template has unbound (dependent) names, or if this is the first time the instantiation is encountered: - Load the pre-parsed template tree and the symbol table at the template definition - Compile the tree, using both symbol tables to look up dependent names (compiling will trigger recursive instantiations, which will start the "search for template definition" step again). 3. Write out the new object file with the compiled instantiations. Somehow, I see this as not really scaring. All this would be step 8, template instantiation, in "2.2 Phases of translation" (between compiling and linking). Symbol tables accompanying all template definitions in the same file will be stored incrementally. The size of pre-parsed trees are likely to be much smaller than symbol tables. In total, the extra disk space required is at most the size of a pre-compiled header times the number of object files. If you actually use a pre-compiled header, cut 3/4 of that or more. Again, I see this as not really scaring, although for real, large projects I admit you may need some extra space. > If this "modules stuff" manages to fix the core of the issue, > that would be even more interesting. [...] Yes but modules are so far away ... I would like export to stay closer. Thank you, Timothy Madden -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Timothy Madden on 26 Jul 2010 23:42 Mathias Gaunard wrote: > On Jul 25, 4:18 pm, Timothy Madden <terminato...(a)gmail.com> wrote: > >> I think the ability to fed the entire program to the compiler at some >> point in the build process (to instantiate templates or for anything >> else) is what is interesting. Never thought about it, but this makes >> the classic compilation model where translation units are compiled >> separately, look old, dusty and unproductive. > > Most modern compilers (GCC, LLVM, MSVC) already allow this, since this > allows to inline functions across translation units boundaries, etc. I am aware of the whole-program /optimizations/, what I am thinking about is a C++ /language/ that is aware of the whole program. Here is an example of the use for a whole-program aware language feature, not related to export: Suppose I have a class Module. That is not really usable by itself, and each application module that needs the functionality in class Module needs to derive from it a class that represents the specific module. Base class Module needs to know about its children classes, and needs to associate a constant to each of them (XmlModule, NetworkModule, ThreadsModule, GUIModule) in order to provide its functionality. This can be done at runtime by providing a static registration function that each actual module is required to call at initialization. But if you think that the count of modules and their identifiers are really compile-time constants you realize how much you could simplify the implementation for base class Module, and you think you should do that. Except really you can not because you do not actually know how many derived classes your users shall define. So you want a language feature like a counter that can be incremented and stored by each derived class, yet the Module base class (and others) have access to it and its final values like a compile-time constant, and derived classes have access to any generated value also as a compile-time constant. Or like an array or an enum, that would be extendable by all derived classes with some declaration / operation, yet the final construct (resulting after all extending declarations in the program) is accessible to the base class as a simple type. Just an example. Somehow I feel there are also better ones that export might even touch. > > It's however less incremental, harder to parallelize, and more > importantly, it doesn't scale as well since it requires to put the > whole of the program into memory, which simply may not fit. > > >> I guess this step is also what you are thinking about ("instantiate >> templates at link-time"). To be frank I find all these very >> interesting and I am surprised people are so much against export. > > Instantiating at link-time is also problematic with dynamic linking. Dynamic libraries can expose no exported templates. Or the program or dynamic loader would need compiler functionality built-in. That is actually conceivable, for example bytecode also needs the VM implementation, either installed in the OS, or included in the executable, in order to run. Lets just say that it is a quality-of-implementation issue and that there are more debatable aspects about export to keep us busy. Thank you, Timothy Madden -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Timothy Madden on 26 Jul 2010 23:41
Pedro Lamar�o wrote: > James Kanze wrote: > >>> Since there is no realistic market for the feature, investing >>> 3 man years into it (and not doing anything else in the >>> meantime) makes no economic sense. >> The problem is that there is no realistic market for the feature >> unless it is widely implemented. A feature which is available >> on just one compiler (and a minority one at that) can't be used, >> regardless of how good it is. > > Which suggests that those who would like to keep it on the standard > should implement it in GCC, and perhaps also Clang. > > If there are enough interested parties out there, perhaps a joint > effort would succeed, or be capable of funding it. > I think an implementation in GCC would be both accessible and would definitely change the situation with export. It is free software and all it takes is a contribution that brings export (of course it will not happen with just a patch). It is wide spread and once the users will see export and get a feeling of it, the "lack of demand" argument will look as demagogic to everyone as it looks to me and a few others now. And I can see the developers on the mailing list are open and have a constructive attitude on it. I can see on GMane (a very very nice server, news.gmane.org, that presents many mailing lists as newsgroups, and has the gcc(a)gcc.gnu.org list archive since june 2002) that export has been discussed there a few times in the past. But for a chance to implement export there, I would like to gather some more rationale and technical details for a paper to propose that export be made optional, instead of being removed, in the next version of C++. I think this would not be pretty much acceptable for parties that want to see export off the list, since optional means optional, and would also be good enough for a chance implement it, since optional means it still exists and has meaning. Anyone with more experience with this can tell me if such a paper would be appropriate or would stand a chance to be considered ? If so, I believe I would need some more technical details to present, and that the subjective reasons on debates on export I should put off without much talk. From what I see by now, the technical problems with export are: - it requires two phase look-up, in which symbols are searched in, and function overloads chosen from, two contexts - symbols used in templates that are static or in anonymous namespaces now behave as if they are extern because of multiple tables lookup - I understand that some more ODR checks need to be made, although it is not clear to me what the issue is - it requires large symbol tables to be stored in object files, for which reason compilation speed may or may not be faster than in the inclusion model - it will at most pseudo-obfuscate template source into an internal parse tree representation. That I guess I will put of nice with the Java bytecode example. The non-technical aspects with export I think I should approach are that: - creating a precedent as C++ does not have such important features as optional until now - keeping it optional is a better idea than removing after 12 years of being in the standard and one or two implementations shipping (Comeau and maybe Intel, which is unfortunately a rather broken implementation for export) - it is not wildly supported after many years, with no public plan from a company to support it (this will be hard to argue with) - it is considered hard to implement - it is sometimes considered of little value. I hope to show that decoupling, if the word is right to use when source code is still needed, and separation for declaration from implementation, actually bring a lot of value. Again, can anyone with more experience give more ideas or details or put in his 2 cents ? Any compiler writers want to give details about approaching export ? Thank you, Timothy Madden -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |