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: Marek Vondrak on 13 Aug 2010 08:31 > Personally, I don't understand what's so hard with implementing link- > time template instantiation when you already have PCH. Because PCH work fundamentally different. They simply serialize the complete compiler state at a given time instant (say, after the compiler has processed #include <windows.h>) and then allow to restore this state at a later compilation of a different TU (so if the other TU also does #include <windows.h>, the compiler can directly load its state from the PCH and skip the include). PCHs, as they are implemented with MSVC, Watcom or Digital Mars, are just state snapshots and can only be used to speed up the compilation of a next TU, if the that TU happens to issue the same set of include directives like the ones that were used in the original TU up to the point when the PCH was saved. -Marek -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 13 Aug 2010 08:32 Mathias Gaunard wrote: > On Aug 13, 3:20 pm, Walter Bright <newshou...(a)digitalmars.com> wrote: > >> As I recall, I pointed out that exported templates offered no fundamental >> technical advantage over precompiled headers in the speed department. >> PCH were >> an existing technology that did produce substantially faster compiles >> (at least >> with Digital Mars C++ they did), though I do not know how widely PCH was >> implemented. > > Export template is quite easier and nicer to use and deploy than PCH. Perhaps, but PCH speeds up everything else in the header files, not just templates. > Personally, I don't understand what's so hard with implementing link- > time template instantiation when you already have PCH. You already > have support for serializing/deserializing your AST to/from an > efficient binary form. All you need to do is embed that data in the > object files (ELF objects shouldn't have any problem with this), then, > before you call the linker, join all that data, and use it to > instantiate and generate code for whatever type an export template was > instantiated with. > > But then, I'm not a compiler writer; maybe there are issues with > actually finding what to serialize in the first place. It's not just the AST. You've also got the symbol table from the file with the template definition to deal with. (PCHs tend to be quite large, on the order of megabytes even for smallish headers. Imagine that stuffed into each object file! Normally, PCH are written once per project, and read once per source file. With this scheme for exported templates, they are read twice and written once per source file.) The real solution is to implement a proper module system for C++. The proof of that is D's experience with it. D doesn't have any special need for exported templates, as it is implicitly part of the module system. Just: import name; and you're done. Modules are hygienic and fast. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andre Kaufmann on 13 Aug 2010 08:31
Hendrik Schober wrote: > Walter Bright wrote: > [...] > > I'm sure that I alone have, in the last decade, seen a lot more man years > than that wasted because of 'export' _not_ being widely available. (If > someone would make a statistics of my newsgroup posting habits, they'd find > the exact date of the above mentioned solution to the problem of long > compilation times -- through distributed compilation -- very easily: It's > the moment my postings during business hours became sparse. That's because > fiddling with templates I wasted time waiting for the compiler, which I > used > to mostly spend reading C++ articles and posting in C++ newsgroups.) I think if all the time, which has been invested into export, would have been invested in a module concept for C++, all the timing problems would be solved (for new and ported code) and nobody (does one really ?) would cry for export anymore. Despite that it's irritating for me that the language which has the best optimizing compilers and is meant to be fast and efficient, is that slow in compilation - there must reasons for that ?! I think that's due to some deficits in the language itself, which have been inherited from C and not the missing "export". Before adding features to hide the effects of a problem, IMHO the root of the problem itself should be fixed. > [...] > Hendrik Schober Andre -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |