rpk@wheaties.ai.mit.edu (Robert Krajewski) (08/06/90)
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 source >text files, separate object files, separate compilation, separate linking. >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. Hear, hear. One consequence of the current mismatch between the current separate compilation schemes and C++ is the following: if you use a data member (say, another class contained directly as a member), you have to include its associated header file, even though that class is used only internally, and none of its normally visible (public) attributes are visible in the containing classes. If you are a non-privileged user of a class, all you need to know about are its size (which, of course, means that to compute its size you must sum the size of its members, and then throw in a little overhead if some virtual functions are involved), and its public members. It would be great if you only dragged in internal information when neccesary. The access level (public, private, protected) can be determined syntactically. 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. Also, all kinds of tools could be written that would give reports of the class hierarchies contained in these interface libraries. -- Robert P. Krajewski Internet: rpk@ai.mit.edu ; Lotus: robert_krajewski.lotus@crd.dnet.lotus.com
steve@taumet.com (Stephen Clamage) (08/06/90)
rpk@wheaties.ai.mit.edu (Robert Krajewski) writes: >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. Wait a minute, wait a minute ... this seems like deja-vu ... I see a vision ... it's ... Ada packages! ... no, it's ... Pascal units! ... no, it's Modula modules! ... Can it be this problem has been solved before? -- Steve Clamage, TauMetric Corp, steve@taumet.com
rfg@NCD.COM (Ron Guilmette) (08/07/90)
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.
scotte@applix.com (Scott Evernden) (08/08/90)
In article <???> (Alfred Benjamin Woodard) writes: >What we need is to get away from the current model of separate source >text files, separate object files, separate compilation, separate linking. >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. I think ParcPlaces's ObjectWorks for C++ comes very close to this model you're proposing. From the very little time I've spent playing with it, I'm convinced that this is the direction we need to move in... -scott
aw1r+@andrew.cmu.edu (Alfred Benjamin Woodard) (08/09/90)
scotte@applix.com (Scott Evernden) writes: > In article <???> (Alfred Benjamin Woodard) writes: I didn't really right this I asked a question and this was the answer? > >What we need is to get away from the current model of separate source > >text files, separate object files, separate compilation, separate linking. > >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. > > I think ParcPlaces's ObjectWorks for C++ comes very close to this model > you're proposing. From the very little time I've spent playing with it, > I'm convinced that this is the direction we need to move in... > > -scott This ObjectWorks sounds like something interesting. Can anybody tell me where I can get some information on this or at least how to get in touch with ParcPlace so I can ask them to send me a brochure. -ben aw1r+@andrew.cmu.edu