C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Standardizing pre-compiled headers          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message dayton Guest Posted: Thu Feb 23, 2006 1:06 am    Post subject: Standardizing pre-compiled headers Its too bad the standards committee isn't looking for wishlist items for C++0X. I hope someone is maintaining a list for C++1X. I see a real need for a standard and more general pre-compiled header feature. Most compilers I've used, including GNU, Sun, Microsoft, have some sort of pre-compiled header feature; but they all suffer from being merely pre-processor aids that don't allow header information compiled for one module being used in another. I've been involved with C++ projects that involved over 3 million lines of code. With code bases that large, even with pre-compiled headers, a build can take hours. That puts a real crimp into continuous integration schemes. This is one of few situations where I actually miss Ada with its compiler libraries. In Ada, everything that gets compiled, gets compiled into a library where other compilation units can access the interfaces. To avoid confusion with linker libraries, I call this type of compiler library a _compiler repository_. A compiler repository may also solve some template instantiation problems. To avoid introducing new keywords, I propose using the "export" keyword to export a namespace into a compiler repository that can be shared between compilations. Use the "using" keyword to import a namespace. To indicate the namespace comes from an external source, surround the namespace name with <>. For example, given a header file with the contents namespace foo { void f(); } export namespace foo; I could import the declarations with using namespace <foo>; or import just foo::f() with using <foo::f()>; The compiler could locate a repository in the same manner we specify the locations of header files. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Francis Glassborow Guest Posted: Thu Feb 23, 2006 3:06 pm    Post subject: Re: Standardizing pre-compiled headers In article <HGVKf.51131$dW3.49019 (AT) newssvr21 (DOT) news.prodigy.com>, dayton <mvglen04-cnews (AT) yahoo (DOT) com> writes Quote: Its too bad the standards committee isn't looking for wishlist items for C++0X. We spent more than four years inviting wishes. At some time if we are to deliver C++0x before 2010 we had to close the wish list and restrict ourselves to dealing with the very substantial pile of things not only wished for but which at least one person had done work on. That time arrived last Autumn (Fall) and even so we will have to triage the proposals actively on offer. -- Francis Glassborow ACCU Author of 'You Can Do It!' see http://www.spellen.org/youcandoit For project ideas and contributions: http://www.spellen.org/youcandoit/projects [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze Guest Posted: Fri Feb 24, 2006 11:06 am    Post subject: Re: Standardizing pre-compiled headers dayton wrote: Quote: Its too bad the standards committee isn't looking for wishlist items for C++0X. I hope someone is maintaining a list for C++1X. I see a real need for a standard and more general pre-compiled header feature. Most compilers I've used, including GNU, Sun, Microsoft, have some sort of pre-compiled header feature; but they all suffer from being merely pre-processor aids that don't allow header information compiled for one module being used in another. How to invoke the compiler is not covered by the standard. And pre-compiled headers come under that category. (If I were writing a compile, it would maintain "pre-compiled" versions of the headers in a data base, with some sort of recursive time-stamp information so that it would know when it had to recompile the header.) Quote: I've been involved with C++ projects that involved over 3 million lines of code. With code bases that large, even with pre-compiled headers, a build can take hours. That puts a real crimp into continuous integration schemes. This is one of few situations where I actually miss Ada with its compiler libraries. In Ada, everything that gets compiled, gets compiled into a library where other compilation units can access the interfaces. To avoid confusion with linker libraries, I call this type of compiler library a _compiler repository_. There's nothing to stop a C++ compiler from doing likewise. Quote: A compiler repository may also solve some template instantiation problems. Don't most compilers already use some sort of repository, to avoid generating multiple instances, and then having to throw most of them out? Quote: To avoid introducing new keywords, I propose using the "export" keyword to export a namespace into a compiler repository that can be shared between compilations. Use the "using" keyword to import a namespace. To indicate the namespace comes from an external source, surround the namespace name with <>. I'm not sure that namespaces can be made to work this way. A namespace is open -- anyone can add anything to it at any time. Using some sort of repository or central data base, it can be made to work, but I don't think that the committee would want to impose anything which required such implementation techniques. There's also the problem as to what the compiler should consider. Suppose I define a namespace Gabi on my machine at home, and you define a namespace with the same name where you work. Obviously, these two namespaces aren't related, and if you say "import namespace Gabi;", you don't want me code, which you know nothing about, and there's no way the compiler on your machine could access my code anyway. But how do you define this line -- suppose I get a contract at your company, and copy my code into my private directories on one of your company's machines? Quote: For example, given a header file with the contents namespace foo { void f(); } export namespace foo; I could import the declarations with using namespace <foo>; or import just foo::f() with using <foo::f()>; The compiler could locate a repository in the same manner we specify the locations of header files. OK. In other words, you want a standard notion of repository, in which the compiler looks automatically. It's not necessarily a bad idea. I think that the Visual Age C++ compiler actually implemented something along these lines. I'm not sure, however, if it doesn't push the standard into an area where it hasn't traditionally gone: the C++ development environment. -- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Kurt Stege Guest Posted: Fri Feb 24, 2006 3:06 pm    Post subject: Re: Standardizing pre-compiled headers kanze wrote: Quote: dayton wrote: I see a real need for a standard and more general pre-compiled header feature. Most compilers I've used, including GNU, Sun, Microsoft, have some sort of pre-compiled header feature; but they all suffer from being merely pre-processor aids that don't allow header information compiled for one module being used in another. How to invoke the compiler is not covered by the standard. And pre-compiled headers come under that category. Yes, of course. And, on the other side, no. Covered by the standard are language features that make it difficult or easy to pre-compile headers. Quote: (If I were writing a compile, it would maintain "pre-compiled" versions of the headers in a data base, with some sort of recursive time-stamp information so that it would know when it had to recompile the header.) You still have the problem that "header" and "#include" have a very complex semantics full of side-effects. When a source code includes five headers, the order is important, and a single define in one header might have heavy influence on the following headers. How would your data-base-repository detect if it can re-use the pre-compiled version of the second header (that has been pre-compiled in another context)? These side-effects are not only a hazzle for pre-compiled headers, they are a hazzle for the developer itself that has to use includes. I just get the idea to #import header files with a different semantics to #include: #import "header" could say: Forget the current context of the compilation unit. Ignore all currently defined pre-processor symbols (and all declared identifiers). Process the file "header" (with the same definition of "file" as used for #include). Merge the context (set of defines and declarations and definitions) from the header files with the current context. Merging is, add all new symbols, accept (and remove) duplicate identical definitions, and provide an error when a duplicate definition differs. When importing headers, the order of importing does no longer matter, you may import one header several times, and there are no side-effects that change the behaviour of a header depending on any previous context. Imported headers can easily be pre-compiled once and re-used for all imports. (Note: I guess, compilers would get another command line option: -D to define pre-processor symbols at the beginning of the compilation unit, and -d to define symbols additionally at the beginning of each imported header.) This importing is a matter that cannot be done by a pure pre-processor(?). Therefore, #import might not be an appropriate notation. How about: using "header"; // a better notation for the same thing? Quote: In Ada, everything that gets compiled, gets compiled into a library where other compilation units can access the interfaces. To avoid confusion with linker libraries, I call this type of compiler library a _compiler repository_. There's nothing to stop a C++ compiler from doing likewise. The language support is missing... Often, a header file has to be processed again, for it results into a different interface due to changed #defines. Best regards, Kurt. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top dayton Guest Posted: Tue Feb 28, 2006 10:06 am    Post subject: Re: Standardizing pre-compiled headers kanze wrote: Quote: There's nothing to stop a C++ compiler from doing likewise. The problem is that header files contain pre-processor definitions which make them order dependent. In C++, redundant declarations are not an error. The semantics of importing namespaces appears to be better defined than including header files. Quote: A compiler repository may also solve some template instantiation problems. Don't most compilers already use some sort of repository, to avoid generating multiple instances, and then having to throw most of them out? Actually, that's the problem -- many popular compilers have very primitive template instantiation. Code bloat with redundantly instantiated templates is still a problem. The GNU compiler doesn't even seem to want to instantiate templates unless you explicitly do it yourself. Quote: I'm not sure that namespaces can be made to work this way. A namespace is open -- anyone can add anything to it at any time. This is an area than can be left to the compiler implementation. Some people may elect to start with a fresh repository on every build, and some may elect to create a repository for every module in a multiple module system. This is equivalent to having to specify the search paths for header files; which the standard does not cover, but most compilers seem to have similar methods of controlling. Quote: There's also the problem as to what the compiler should consider. Suppose I define a namespace Gabi on my machine at home, and you define a namespace with the same name where you work. Obviously, these two namespaces aren't related, and if you say "import namespace Gabi;", you don't want me code, which you know nothing about, and there's no way the compiler on your machine could access my code anyway. But how do you define this line -- suppose I get a contract at your company, and copy my code into my private directories on one of your company's machines? The standard specifies namespace aliases so you may give the foreign namespace another name. You have this problem anyways with header files that define any identifier. You copy a set of header files from one site to another, there will be conflicts unless you wrap in namespaces, use namespace aliasing, or just modify the files. Another use for a compiler repository is to allow header files in other languages, e.g. ANSI C or IDL, to be compiled into the repository with other compilers that produce the repository format. This may give the C++ language more freedom to change in that existing code can be compiled and used in the repository, but new code could be written using refined syntax not compatible with the old language. Thank you for your excellent rational arguments. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Mike Capp Guest Posted: Wed Mar 01, 2006 12:06 pm    Post subject: Re: Standardizing pre-compiled headers [repost with quote for context...] dayton wrote: Quote: Its too bad the standards committee isn't looking for wishlist items for C++0X. I hope someone is maintaining a list for C++1X. I see a real need for a standard and more general pre-compiled header feature. Daveed Vandevoorde's 'Modules in C++' proposal did pretty much what you want, and would allow complete migration away from #include to boot. Latest public version is at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1778.pdf The last discussion I saw on it was over a year ago, though, so I don't know whether it's still being actively pursued. It'd be a shame if not. At last count I had some concerns about how to report dependency information to 'make'-like build tools, but overall it looked very good. HTH, Mike [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Guest Posted: Thu Mar 02, 2006 9:06 am    Post subject: Re: Standardizing pre-compiled headers Mike Capp wrote: [...] Quote: Daveed Vandevoorde's 'Modules in C++' proposal did pretty much what you want, and would allow complete migration away from #include to boot. Latest public version is at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1778.pdf I managed to slip an update in the latest mailing, which made it to the open-std site shortly after you posted that URL. Here is the new one: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1964.pdf I didn't have as much time as I had hoped for to produce this update, and (unlike the previous version) I did not have a chance to have it reviewed by others. Still, let me know what you think. Daveed [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT Page 1 of 1   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.