Re: Support for export keyword to use with C++ templates ?
On Sat, Mar 10, 2012 at 6:35 AM, Timothy Madden wrote: > On 25.01.2010 20:12, Ian Lance Taylor wrote: >> >> Timothy Madden writes: > > [...] > >> >> g++ is free software. A clean implementation of export would >> certainly be accepted. All it takes is for somebody to write one. > > > Hello > > Is that statement above still true please ? > > I know export is now to be made deprecated by the next version of the C++ > standard On a point of information: Support for exported templates has been removed, not merely deprecated, in the current version of the C++ standard (C++11). -- James
Re: Support for export keyword to use with C++ templates ?
On 25.01.2010 20:12, Ian Lance Taylor wrote: Timothy Madden writes: [...] g++ is free software. A clean implementation of export would certainly be accepted. All it takes is for somebody to write one. Hello Is that statement above still true please ? I know export is now to be made deprecated by the next version of the C++ standard, but I am still interested in what does it take to implement it in gcc and how would a possible design look like. For this, I remember that in times long forgotten someone on this list actually tried to negotiate implementing export with some potential "client" or interested party. They must have quickly gave up back then since to my knowledge export has not been approached in gcc yet. But if you please have or you can remember any design approach/decisions for export made then, it will very much help me to know about it. Than I would like to get your opinion if possible with the sort of "design" I could come up with at a first attempt. First, I am interested in a design for export that does not require sources to be available for the instantiation phase. For this, .cc files would compile into several files file: - the regular object file .obj - some shared, project-global .sym file with a repository of immutable (read-only) symbols from the symbol table, for symbols encountered throughout the entire program. - some .tpl file with the parse tree for the template definitions, together with references (into the .sym file) for all symbols in the symbol table at the point of definition - some .tpi file listing the template instantiations (usages), or the s with references to the entire symbols table at every point of instantiation. This references are indexes into the symbols repository. The above are generated at translation phase, which needs to prepare everything for instantiation. After a complete compilation, the symbols repository will most likely collect symbols from the entire project, including static symbols. Each symbol in the repository has to be properly indexed and versioned, to allow both complete and incomplete definitions for the same symbol, and to allow multiple static symbols with the same name. Each symbol should also include a list of .tpl and .tpi files that reference them. In this way when a source file is re-compiled and it no longer uses a given symbol, it can be removed from the repository. Its index/version number is not re-used. The repository is extended/updated as each source file is being compiled/recompiled when the .tpl/.tpi files are generated. Any symbol referenced from the .tp? files is added to the repository if not already there. The instantiation phase then needs only the above three files (.sym, .tpl, .tpi), and from them it generates some additional object code for the linker. When instantiation triggers other instantiations, multiple .tpl files join the context. This is where the look-up in multiple symbol tables has to be done. It is here when the ODR has to be checked. Every template that gets instantiated keeps a record of all symbols that were looked up for it, together with the look-up result for each. I will need some symbol look-up log file .slk for that. Think of it like a replication log file for database replication. Then, when an instantiation is encountered for the same template-id (same template, same arguments), the template need not be re-compiled, but the sequence of symbol look-ups has to be replicated, to ensure the same results are produced at the new point of instantiation. If look-up results differ, a smart error message (suggestions welcome) will be output. This is where I got until now. My problems now are: - the old parallel-compilation-problem. A shared repository can not really be accessed by multiple gcc instances without database-like locking, which I think is not the domain of gcc. So I think I could allow like 4 such repositories to be created and used in parallel, for a quad-core CPU , and have the fifth gcc instance that fires up enter a locking wait state based on a lockfile, until one of the other four is done. - the repository file size. I hear pre-compiled header files are 50 to 200 MB in size. Since the repository includes symbols from the entire program, not only standard headers, I expect it will be up to twice as large. I guess each client will have to decide for themselves if this size is a good price to pay for the export feature. - it is still not clear to me how to keep the repository up-to-date when only some of the source files change. - I would like to know if it would be useful for all these files types to have a public format, so they can be used by
Re: Support for export keyword to use with C++ templates ?
Dodji Seketeli wrote: > On Sat, Jan 30, 2010 at 01:47:03AM +0200, Timothy Madden wrote: > >> So nobody here wants to try a big thing ? :( >> > > This question strikes me as being not very fair because many GCC people > are already pretty much involved. Would you fancy giving a hand? > > >> How long would it take for someone to understand how parsing works in >> g++ ? Or to understand the build system in gcc ? >> > > It depends (amongst other things) on the motivation of said person, I > guess. Maybe several months? As usual in this kind of things, I guess a > good approach is to try to scratch your own itches without thinking too > much about the time it would take, especially for something as big as > this particular feature you are talking about :-) > > Dodji > I'd like to remind people that the EDG people expect this to need something between two and three man-years. That seems to mean as a full-time job. That's four to six *years* if you spend half your working time on it. Something to think about.
Re: Support for export keyword to use with C++ templates ?
> It depends on who owns the code that you write. If you own the code, > then you need to sign papers as an individual contributor. I don't think it's that simple. "who owns the code" is not always clear. There's often a question of who that is. That's why if somebody HAS an employer we usually ask for a disclaimer from that employer even when the person doesn't think their employer has any claims on the code.
Re: Support for export keyword to use with C++ templates ?
> I do not know the correct wording in English for this but I am legally > licensed as an individual to offer software consulting services and to > develop software. > > So the so-called employer is really my client, with whom I have signed > a contract for consulting services. If you have exactly one client, then I would treat them as an "employer" for this purpose and get a disclaimer from them. If you have multiple clients, I'd suggest asking the FSF directly since this is a potentially tricky situation.
Re: Support for export keyword to use with C++ templates ?
Timothy Madden writes: > On Wed, Feb 3, 2010 at 4:19 AM, Richard Kenner > wrote: >>> I see that what I need is an assignment for all future changes. If my >>> employer is not involved with any contributions of mine, the employer >>> disclaimer is not needed, right ? >> >> It's safest to have it. The best way to prove that your employer is >> not involved with any contributions of yours is with such a disclaimer. > > The term "employer" is inappropriate for legal purposes in my case as > I am a self-employed individual or a freelancer. > > I do not know the correct wording in English for this but I am legally > licensed as an individual to offer software consulting services and to > develop software. > > So the so-called employer is really my client, with whom I have signed > a contract for consulting services. > > What legal papers would I need for this ? It depends on who owns the code that you write. If you own the code, then you need to sign papers as an individual contributor. Thanks. Ian
Re: Support for export keyword to use with C++ templates ?
On Wed, Feb 3, 2010 at 4:19 AM, Richard Kenner wrote: >> I see that what I need is an assignment for all future changes. If my >> employer is not involved with any contributions of mine, the employer >> disclaimer is not needed, right ? > > It's safest to have it. The best way to prove that your employer is > not involved with any contributions of yours is with such a disclaimer. The term "employer" is inappropriate for legal purposes in my case as I am a self-employed individual or a freelancer. I do not know the correct wording in English for this but I am legally licensed as an individual to offer software consulting services and to develop software. So the so-called employer is really my client, with whom I have signed a contract for consulting services. What legal papers would I need for this ? Thank you, Timothy Madden
Re: Support for export keyword to use with C++ templates ?
On 02/02/2010 05:04 AM, Michael Witten wrote: On Sun, Jan 31, 2010 at 6:38 PM, Paolo Carlini wrote: it's extremely unlikely that the C++ front-end maintainers could even consider reviewing patches from a novice for such an hard to implement feature. That says more about the tangled mess that is gcc then about any particular programmer's ability. That says more about how deeply you have looked at the front-end's sources than about anything else. ^ Paolo
Re: Support for export keyword to use with C++ templates ?
On 2/2/10 7:19 PM, Richard Kenner wrote: I see that what I need is an assignment for all future changes. If my employer is not involved with any contributions of mine, the employer disclaimer is not needed, right ? It's safest to have it. The best way to prove that your employer is not involved with any contributions of yours is with such a disclaimer. Some employers have had a formal process for approving assignment of own-time contributions, as well as assignments as part of their business, and lack of either form of assignment indicates the employer has forbidden them. -- Tim Prince
Re: Support for export keyword to use with C++ templates ?
> I see that what I need is an assignment for all future changes. If my > employer is not involved with any contributions of mine, the employer > disclaimer is not needed, right ? It's safest to have it. The best way to prove that your employer is not involved with any contributions of yours is with such a disclaimer.
Re: Support for export keyword to use with C++ templates ?
On Mon, Feb 1, 2010 at 2:38 AM, Paolo Carlini wrote: > On 02/01/2010 01:26 AM, Timothy Madden wrote: [...] > As I see the issue, you should first check over the next months that the > feature is not deprecated by ISO. I know, I tried to talk about it on std.c++. I am afraid I can not see a consensus in the end, still I would not say the committee will just remove it. They were strongly against deprecation in 2003. > Then start learning about the > internals of GCC and eventually propose a detailed plan explaining how > you want to attack the problem, because before that it's extremely > unlikely that the C++ front-end maintainers could even consider > reviewing patches from a novice for such an hard to implement feature. Yes it is. I wish there were a nice and easy way about it, but an attempt at export is something quite big ... > That said, if you *really* plan contributing to GCC, maybe outside > export first (which seems a terribly good idea to me) first and > foremost, read the relevant web page: > > http://gcc.gnu.org/contribute.html > > and start immediately the paperwork for the Copyright assignment, > because it takes time. I see that what I need is an assignment for all future changes. If my employer is not involved with any contributions of mine, the employer disclaimer is not needed, right ? It is going to be a while until I will be able to submit any kind of patch; should I start with the paperwork ? Thank you, Timothy Madden
Re: Support for export keyword to use with C++ templates ?
On Sun, Jan 31, 2010 at 6:38 PM, Paolo Carlini wrote: > it's extremely > unlikely that the C++ front-end maintainers could even consider > reviewing patches from a novice for such an hard to implement feature. That says more about the tangled mess that is gcc then about any particular programmer's ability.
Re: Support for export keyword to use with C++ templates ?
Timothy Madden writes: > On Sat, Jan 30, 2010 at 4:05 AM, Paolo Carlini > wrote: > [...] >> Even for implementors knowing *very* well both the details of the C++ >> standard and the internals of a specific front-end, implementing export >> is an *highly* non-trivial task. [...] > > Yes, everyone is telling me that, but could someone please describe a > little what would be the first problems that would have to be > addressed for export with the current g++ implementation ? Or > summarise the steps that would have to be taken for a first attempt at > export ? Aside from what Paolo said, the first requirement is clearly going to be the ability to write out and read in the frontend IR. Ian
Re: Support for export keyword to use with C++ templates ?
On 02/01/2010 01:26 AM, Timothy Madden wrote: > Since such a change must happen in small steps, I would be interested > to know how 'acceptable' would a limited implementation be at first ? > Like the command line options I have seen declared 'experimental' in > the gcc manual before ... > As I see the issue, you should first check over the next months that the feature is not deprecated by ISO. Then start learning about the internals of GCC and eventually propose a detailed plan explaining how you want to attack the problem, because before that it's extremely unlikely that the C++ front-end maintainers could even consider reviewing patches from a novice for such an hard to implement feature. That said, if you *really* plan contributing to GCC, maybe outside export first (which seems a terribly good idea to me) first and foremost, read the relevant web page: http://gcc.gnu.org/contribute.html and start immediately the paperwork for the Copyright assignment, because it takes time. Paolo.
Re: Support for export keyword to use with C++ templates ?
On Sat, Jan 30, 2010 at 4:05 AM, Paolo Carlini wrote: [...] > Even for implementors knowing *very* well both the details of the C++ > standard and the internals of a specific front-end, implementing export > is an *highly* non-trivial task. [...] Yes, everyone is telling me that, but could someone please describe a little what would be the first problems that would have to be addressed for export with the current g++ implementation ? Or summarise the steps that would have to be taken for a first attempt at export ? Did someone here said they tried some things before ? Thank you, Timothy Madden
Support for export keyword to use with C++ templates ?
On Sat, Jan 30, 2010 at 4:23 AM, Michael Witten [...] > However, I have a gut feeling that at least a restricted version of > 'export' (or a cousin of 'export') could be both useful and trivial to > implement: [...] > Those were my thoughts too. Since such a change must happen in small steps, I would be interested to know how 'acceptable' would a limited implementation be at first ? Like the command line options I have seen declared 'experimental' in the gcc manual before ... The idea of a "cousin of" or "variation of" is less important though, as I am interested in standard conformance, even if partly implemented. Timothy Madden
Re: Support for export keyword to use with C++ templates ?
On Sat, Jan 30, 2010 at 01:47:03AM +0200, Timothy Madden wrote: > So nobody here wants to try a big thing ? :( This question strikes me as being not very fair because many GCC people are already pretty much involved. Would you fancy giving a hand? > How long would it take for someone to understand how parsing works in > g++ ? Or to understand the build system in gcc ? It depends (amongst other things) on the motivation of said person, I guess. Maybe several months? As usual in this kind of things, I guess a good approach is to try to scratch your own itches without thinking too much about the time it would take, especially for something as big as this particular feature you are talking about :-) Dodji
Re: Support for export keyword to use with C++ templates ?
Paolo Carlini writes: > Anyway, modulo a possible deprecation (I believe M$ through Herb is > still pushing for it) I think the slightly more serious side of this > export thing is something Mark, if I'm not mistaken, said some time > ago, at the very beginning of the Lto ideas, to the effect that > probably some infrastructure could be also used to attack the > implementation of export. Does that make sense to anybody? The LTO infrastructure could probably be somewhat useful to anybody who wants to tackle export. However, it will only be somewhat useful. LTO provides the ability to write out GIMPLE. But to support export you need to instead stream out the C++ frontend representation, which is trees. In the gcc way, there is overlap between GIMPLE and trees, but they are not the same thing. So a bunch more work will still be required even for the first basic step of export, which is the ability to write out a parse tree. Ian
Re: Support for export keyword to use with C++ templates ?
Hi I already tried to tell him that upthread. Sorry about that, last night was tired and didn't follow the whole thread. Anyway, modulo a possible deprecation (I believe M$ through Herb is still pushing for it) I think the slightly more serious side of this export thing is something Mark, if I'm not mistaken, said some time ago, at the very beginning of the Lto ideas, to the effect that probably some infrastructure could be also used to attack the implementation of export. Does that make sense to anybody? Paolo
Re: Support for export keyword to use with C++ templates ?
On Fri, Jan 29, 2010 at 06:23:45PM -0800, Michael Witten wrote: > On Fri, Jan 29, 2010 at 8:05 PM, Paolo Carlini > wrote: > > Even for implementors knowing *very* well both the details of the C++ > > standard and the internals of a specific front-end, implementing export > > is an *highly* non-trivial task. > > However, I have a gut feeling that at least a restricted version of > 'export' (or a cousin of 'export') could be both useful and trivial to > implement: Perhaps a limited form could simply automate the > not-infrequently employed practice of creating a translation unit > specifically for explicit template instantiations. The typical implementations have all sorts of problems: where do you store these extra explicit template expansions? If you make a database for the template expansions, you have locking problem, or experience frequent corruption or the like; I've had such problems making such systems work that we've generally resorted to turning it off (e.g. tell Sun's compiler to expand templates into static functions). These problems might be overcome, but it hasn't been done because it is a hard problem. The main difficulty is building a robust flow that supports parallel builds and an efficient link pass.
Re: Support for export keyword to use with C++ templates ?
Paolo Carlini writes: > On 01/30/2010 01:14 AM, Ian Lance Taylor wrote: >> I don't think you need to understand the build system to implement >> export in C++. You do clearly need to understand the g++ frontend. >> However, it's impossible for me to estimate how long it would take >> somebody to understand it. It would depend greatly on that person's >> experience as a programmer and knowledge of C++. gcc's C++ frontend >> is probably some 150,000 lines of code, considering everything. >> > Even for implementors knowing *very* well both the details of the C++ > standard and the internals of a specific front-end, implementing export > is an *highly* non-trivial task. You can probably find this paper useful: > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf I already tried to tell him that upthread. Ian
Re: Support for export keyword to use with C++ templates ?
On Fri, Jan 29, 2010 at 8:05 PM, Paolo Carlini wrote: > Even for implementors knowing *very* well both the details of the C++ > standard and the internals of a specific front-end, implementing export > is an *highly* non-trivial task. However, I have a gut feeling that at least a restricted version of 'export' (or a cousin of 'export') could be both useful and trivial to implement: Perhaps a limited form could simply automate the not-infrequently employed practice of creating a translation unit specifically for explicit template instantiations. Sincerely, Michael Witten
Re: Support for export keyword to use with C++ templates ?
On 01/30/2010 01:14 AM, Ian Lance Taylor wrote: > I don't think you need to understand the build system to implement > export in C++. You do clearly need to understand the g++ frontend. > However, it's impossible for me to estimate how long it would take > somebody to understand it. It would depend greatly on that person's > experience as a programmer and knowledge of C++. gcc's C++ frontend > is probably some 150,000 lines of code, considering everything. > Even for implementors knowing *very* well both the details of the C++ standard and the internals of a specific front-end, implementing export is an *highly* non-trivial task. You can probably find this paper useful: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf Paolo.
Re: Support for export keyword to use with C++ templates ?
Timothy Madden writes: > How long would it take for someone to understand how parsing works in > g++ ? Or to understand the build system in gcc ? I don't think you need to understand the build system to implement export in C++. You do clearly need to understand the g++ frontend. However, it's impossible for me to estimate how long it would take somebody to understand it. It would depend greatly on that person's experience as a programmer and knowledge of C++. gcc's C++ frontend is probably some 150,000 lines of code, considering everything. Ian
Re: Support for export keyword to use with C++ templates ?
On Mon, Jan 25, 2010 at 8:12 PM, Ian Lance Taylor wrote: > Timothy Madden writes: > >> On Fri, Jan 22, 2010 at 2:24 AM, Ian Lance Taylor wrote: >>> Timothy Madden writes: >>> 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." >> >> I have seen that paper in the link, N1426, and I find it to be biased >> against export ... > > It may be biased, but I think it does a nice job of explaining why it > is so hard to store template definitions and the set of symbols > visible to them. No, it only scares people off the subject ... So nobody here wants to try a big thing ? :( How long would it take for someone to understand how parsing works in g++ ? Or to understand the build system in gcc ? Thank you, Timothy Madden
Re: Support for export keyword to use with C++ templates ?
Timothy Madden writes: > On Fri, Jan 22, 2010 at 2:24 AM, Ian Lance Taylor wrote: >> Timothy Madden writes: >> >>> 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." > > I have seen that paper in the link, N1426, and I find it to be biased > against export ... It may be biased, but I think it does a nice job of explaining why it is so hard to store template definitions and the set of symbols visible to them. g++ is free software. A clean implementation of export would certainly be accepted. All it takes is for somebody to write one. I know that seems like a non-answer, but as far as I can tell there is currently no constituency for adding export to g++. It's not something which people routinely complain about. There are C++ frontend issues which people do routinely complain about, such as bad error messages and compilation speed, and gcc developers do work on those areas. Ian
Re: Support for export keyword to use with C++ templates ?
On Fri, Jan 22, 2010 at 2:24 AM, Ian Lance Taylor wrote: > Timothy Madden 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 lik
Re: Support for export keyword to use with C++ templates ?
Timothy Madden 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. Ian
Support for export keyword to use with C++ templates ?
Hello Is there any progress or start yet in implemententing export for C++ templates ? A search in the mailing list archive shows the last time the issue was discussed was in 2006. Why is everybody such not interested in this ? It would be such a great feature, especially for a leading C++ implementation like gcc ... 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 ? A compiler-provided tool (or even the compiler) would then be invoked as a separate step in the build process before linking, being passed all such object files (named translated translation units by the standard) in the program, same as the linker is given all the object files. This tool would then examine the translated units in order to: - identify the required template instantiations, - find the template definitions - instantiate them (event in a separate output file, later to be passed to the linker as an object file) It is a matter of giving the compiler (compiler-provided tool) access to all translation units in the program at some point before linking, in a new step in the build process. Such a tool would share attributes of: - a compiler, in that it generates object code, but only from the encoded template definitions, and - a linker, in that it has the entire program at its disposal and it resolves references, but only references between required template instantiations and template definitions. To put it simple though it is just: "the compiler having all the object files of a program", or like having gcc understand a some type of input file: parsed-template-definition object files, and then have gcc output some regular object file from this new input files. The linker in the end should stay out of all these and only get the instantiated, regular object files. So a Makefile to explicitly go through the build steps would be like array_tmpl.o: array_tmpl.cc g++ -c -o array_tmpl.o array_tmpl.cc hash_tmpl.o: hash_tmpl.cc g++ -c -o hash_tmpl.o hash_tmpl.cc main.o: main.cc g++ -c -o main.o main.cc templ_inst.o: main.o array_tmpl.o hash_tmpl.o g++ -instantiate-only -o templ_inst.o main.o array_tmpl.o hash_tmpl.o main: main.o array_tmpl.o hash_tmpl.o templ_inst.o ld main.o arrray_tmpl. hash_tmpl.o templ_inst.o Any thoughts ? Thank you, Timothy Madden
