Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!lupine!rfg From: rfg@NCD.COM (Ron Guilmette) Newsgroups: comp.lang.c++ Subject: Re: C++ Linkage, Interface Issues Message-ID: <1103@lupine.NCD.COM> Date: 6 Aug 90 20:44:44 GMT References: <383@taumet.com> <9714@rice-chex.ai.mit.edu> Organization: Network Computing Devices, Inc., Mt. View, CA Lines: 68 In article <9714@rice-chex.ai.mit.edu> rpk@rice-chex.ai.mit.edu (Robert Krajewski) writes: >In article <383@taumet.com> steve@taumet.com (Stephen Clamage) writes: >>aw1r+@andrew.cmu.edu (Alfred Benjamin Woodard) writes: >>What we need is to get away from the current model of ... >>... separate compilation... >>We need a more integrated environment. For example, typical real-world >>C programs may include thousands of lines of header files for each >>module, the header files processed over and over. This is very wasteful. >> >>The editing/compiling/linking processes could be more integrated, whereby >>a database is maintained to keep track of things. As you edit a >>program, it could be incrementally compiled, incrementally linked, as >>you go. This would dramatically improve productivity. > ... >What is needed is a new kind of library, an interface library, that >contains, effectively, a pre-digested form of what is found in header >files. Of course, a new kind of library would require new code and >changes to compilers, but the benefit would be the end of brainless >and slow reparsing of header files... Since the issue has arisen, I just thought that I would mention that I am now in the process of implementing a simple but efficient separate compilation facility in GNU g++. I plan to present all of the details at a later date. I will post a paper on the facility and its implementation here and in comp.std.c++. For those who may wish a sneak preview however, I can summarize as follows. Each compilation unit (or "module" if you prefer) is composed of two parts, i.e. interface and implementation. In place of `interface' and `implementation', we can use the names "public" and "private" for these two parts (respectively). The public part of a module consists of all of the declarations and definitions in the module down to the first `public:' specifier found at global scope. If there is no `public:' specifier in the module at global scope then the everything in the module is public. The private part of a module is everything that comes after the `private:'. Compilation options allow you to compile either for the purpose of creating an object file (in which case the entire module is compiled) or you may compile strictly for the purpose of creating an `interface' file, or you can do both at once. An `interface' file (or .I file) consist of a condensed, pre-masticated representation of the public declarations of a corresponding source module. It also contains representations for inline function definitions (at least those that the compiler *can* in fact do inlining on). If you compile just to generate an interface file, compilation stops at the `private:' tag that starts the private part of the module. To make use of a previously created interface file, you must `import' the declarations and definitions from that interface file into some other source module. I wanted to invent an "import" statement, but that would add a new keyword unnecessarily. Thus, to import the declarations from a given (pre-existing) interface file called, say, "foo.I" into some other module, you would write: public "foo"; at the global level and at some reasonable point within the importing module. That all there is to it. -- // Ron Guilmette - C++ Entomologist // Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg // Motto: If it sticks, force it. If it breaks, it needed replacing anyway.