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: Francis Glassborow on 30 Jul 2010 23:34 Timothy Madden wrote: > Walter Bright wrote: > [...] >> Don't get me wrong, I'm not criticizing you for being enthusiastic about >> this >> feature and thinking it will work. Often times, fundamental advancements >> are >> made by people who reject the conventional wisdom and find a way. The >> source >> code is available for many C++ compilers, including g++ and Digital Mars >> C++. >> Feel free to organize some like-minded developers and try out your ideas. > > How would I do that when the committee is on to removing export ? :( > > Thank you, > Timothy Madden > An IS is supposed to standardise existing practice. WG21 has on several occasions ignored this (and with a lot of justification) However when 12 years after introducing a creative invention to resolve an impasse in the committee it is not available to most users and we have absolutely no reason to expect it ever to be. (however you look at it, that was the primary motivation for the introduction of export, WG21 and J16 were very close to meltdown at the meeting prior to its introduction -- I was there and as a Head of Delegation I think I know all the details) If after 12 years something is essentially just ink on paper and the only people to have done anything about it (implement it) support its removal WG21 would not be doing its job if it were to leave it in. AFAICS no NB commented on its removal in the comments to the recent ballot on the FCD so it is time, IMNSHO, to face reality, C++0x will be a step closer to standardising existing paractice because export will not be in it. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 31 Jul 2010 01:20 Timothy Madden wrote: > Walter Bright wrote: >> Timothy Madden wrote: >>> Walter Bright wrote: >>>> For one thing, it requires that the compiler maintain some sort of >>>> global database of precompiled templates. Managing that database is a >>>> time sink, >>>> and comes with its own set of problems. >>> I have heard this idea before, but how is this required ? >> >> If the compiler is compiling foo.cpp, and it contains an exported >> template declaration, the compiler has no clue from the source code >> where it might find that template definition. >> >> Therefore, there must be some sort of global database the compiler can >> consult and update. > > The idea is the template definition is only needed at template > instantiation time. I will compile foo.cpp /without/ the template > definitions, and instead include the symbol table as it was at the end > of the unit, in the generated object file. > > At the template instantiation phase (translation phase 8, a new step > between compiling and linking) the compiler has all the object files, > finds the pre-parsed template definition in one of them, and then > completes the compilation of foo.cpp using the stored symbol table to > compile the needed templates. > > There is no such global database involved, except maybe for some > optimizations if you will. The global database is, in this scenario, the collection of object files containing the stored symbol tables and template definitions you present to whatever program implements step 8. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 31 Jul 2010 01:20 Timothy Madden wrote: > Walter Bright wrote: > [...] >> Don't get me wrong, I'm not criticizing you for being enthusiastic about this >> feature and thinking it will work. Often times, fundamental advancements are >> made by people who reject the conventional wisdom and find a way. The source >> code is available for many C++ compilers, including g++ and Digital Mars C++. >> Feel free to organize some like-minded developers and try out your ideas. > > How would I do that when the committee is on to removing export ? :( The Committee doesn't dictate anything to you. You are free to start with those compiler sources and implement whatever you wish. If your project winds up proving that exported templates are a great idea, then I would expect that to carry a lot of weight with the Committee in considering adopting it. I am not on the Committee and do not speak for it, but given the history of export, I expect that the members will not give the time of day to someone simply arguing for export. A practical implementation demonstrating it's a good idea would be the only thing that'll get an audience. Keep in mind that the only existing implementation failed to prove it's a good idea. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andre Kaufmann on 31 Jul 2010 01:22 Louis Lavery wrote: > > [...] > I rarely use #defines (apart from the include guards in my .hpp and > ..cpp files), and when I do it's a #define in a header and the #ifdef > or #ifndef in the .cpp or .hpp. So it's not a problem for me. That It's a problem for the compiler and sometimes for the developer too. > [...] > I like header files. As others have said, they separate the interface The header file system introduces IMHO more complexity than needed. (pimpl for separation, include guards -> multiple inclusion, "thousand" includes in a header and implementation file ...) Separation of interface and implementation can be done (optionally) in a single file. The main advantage of modules would be, that C++ could get rid of some bad design decisions, inherited from C. > [...] > Louis. Andre -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Timothy Madden on 31 Jul 2010 23:33
Walter Bright wrote: > Timothy Madden wrote: [...] >> The idea is the template definition is only needed at template >> instantiation time. I will compile foo.cpp /without/ the template >> definitions, and instead include the symbol table as it was at the end >> of the unit, in the generated object file. >> >> At the template instantiation phase (translation phase 8, a new step >> between compiling and linking) the compiler has all the object files, >> finds the pre-parsed template definition in one of them, and then >> completes the compilation of foo.cpp using the stored symbol table to >> compile the needed templates. >> >> There is no such global database involved, except maybe for some >> optimizations if you will. > > The global database is, in this scenario, the collection of object files > containing the stored symbol tables and template definitions you present to > whatever program implements step 8. That would be the compiler (or a compiler tool or compiler-provided tool), because template instantiation means actual template compilation from pre-parsed source. Anyway, if the object files are that database, then I see no locking problem there, even if source files are compiled separately or in parallel. Final template instantiation works on all object files at once, like linking, except that you can also perform instantiation on a subset of them if you want. For example if most of the templates are written by you and you use only a few templates written by other programmers in the project than you can instantiate templates using only your object files to test your changes or compilation results. When the program is ready, for example you are ready to commit changes to source code control, the entire project will be compiled and templates still to be instantiated are also found. If you want instantiation on two subsets of object files at the same time you get to the locking problem ... :) Thank you, Timothy Madden -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |