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: Timothy Madden on 30 Jul 2010 11:24 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. But since people warn about it that it is unsafe, I guess there will be none. 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 30 Jul 2010 11:23 Peter C. Chapin wrote: > On 2010-07-28 01:32, Walter Bright wrote: > >> The best way forward for you is to develop this feature yourself, and >> prove it works, delivers real benefits and has a sizable constituency, > then take >> it to the Committee with an incorporation proposal. > > It probably makes sense to do this with the module proposal rather than > with export. If one reviews the literature on export it is easy to see > that there are many problems and concerns with it. An experimental > implementation of C++ modules would probably be a greater service to the > community at this point than fighting with export. This is one subject I am very interested in: what literature is there on 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! ]
From: Timothy Madden on 30 Jul 2010 11:25 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 -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 30 Jul 2010 11:23 Keith H Duggar wrote: > On Jul 29, 9:15 am, Walter Bright <newshou...(a)digitalmars.com> wrote: >> Why do namespaces fail to resolve this issue (aside from the >> preprocessor)? > > For one there is a need for automatically generating unique > easy to use one-off names for helper/detail functions etc. > Currently anonymous namespaces do this per translation unit. > So I can without fear use short generic names for helpers > etc for example: > > a.cpp > namespace { > void dump ( ) { ... } > } > > b.cpp > namespace { > void dump ( ) { ... } > } > > if both a.cpp and b.cpp are included at the bottom on the > .hpp file then when that .hpp is eventually included in some > .cpp translation unit there will be name clashes. > > The problem turns from annoying to dangerous when there are > overloaded helper/detail functions because then instead of > getting ambiguity errors your code just silently changes. Thanks, that's pretty much what I thought. The problem is that C++ namespaces are not closed, in that later on the namespace's name space can be added to. I feel this is a serious error in the design of namespaces, but fixing that would be enormously easier than implementing exported templates. (After all, one cannot add to a function, struct, enum, etc., after its closing brace.) > And, no, forcing users to generate their own unique names for > helper namespaces (ala private_someunique) and requiring them > to prefix throughout and/or telling them they should just nest > everything into their already unique class name (ala Java) are > not acceptable "solutions". In a sensible implementation of imports, the modules being imported must each exist in their own, closed, name spaces. So, one way or another, you'll need to name each source module with a unique name. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Mathias Gaunard on 30 Jul 2010 23:35
On Jul 31, 3:23 am, Walter Bright <newshou...(a)digitalmars.com> wrote: > The problem is that C++ > namespaces > are not closed, in that later on the namespace's name space can be added > to. There would be no much point to namespaces if they were closed, because you could achieve the same thing by using classes with static members. (well granted, it's a bit different due to ADL) -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |