coggins@coggins.cs.unc.edu (Dr. James Coggins) (11/01/88)
At the Denver C++ Conference I presented some practical tips and organizational strategies for managing C++ libraries, including a strategy for keeping track of .h files with minimal programmer effort. This was the most enthusiastically received presentation I have ever given (thanks folks!). About 100 copies of the transparencies I used were made available at the conference (thanks to Austin Andres of U.S. West-Denver for making them), and they disappeared rapidly. Since there appears to be demand for practical tips and techniques of this sort, graduate student Greg Bollella and I will post to this newsgroup over the next few days a series of articles describing how we have organized and optimized my C++ library. (My library includes classes for 3-D computer graphics and image pattern recognition to support my research, but is of interest here only in that it is large - about 60 classes, with lots of dependencies, requiring solutions to library management problems.) We welcome comments by e-mail; if questions of general interest are raised we'll extend our series of articles to address them. E-mail to coggins@cs.unc.edu or uunet!mcnc!unc!coggins. We hope you find these suggestions useful; if you can improve on them, even better! ------------------------------------------------------------------------ Managing C++ Libraries Part 1: Problems in Library Management Libraries of C++ classes help users to exploit predefined encapsulations, so they are essential to achieving the goals of code reuse prominent as a justification for object-oriented design. We have encountered and solved several problems in using and managing a large and complex C++ class library. Since other C++ users are encountering similar difficulties, we will describe our solutions in a series of articles in this news group. This article is an introduction to briefly describe the problems we have encountered. Our solutions will be described in later postings. A problem we have encountered with AT&T cfront 1.2.1 is the production of excessively large executable files. This problem was solved, in part, by the use of CC command options that are documented in the cfront release notes. That documentation describes what the options do but not how to use them. We will describe how we use these options to obtain an order-of-magnitude decrease in the size of our library's .a file. (see Managing C++ Libraries: Using +e0 and +e1) An appropriate arrangement of subdirectories for a library can simplify the management of the library by its developers and understanding of the library by its users. We will describe our scheme for organizing the code of a library into subdirectories. Another issue in library management is whether to store member functions in separate .c files or to keep all member functions for a class in a single .c file. We will describe the tradeoffs we have discovered between these organizational strategies. (see Managing C++ Libraries: Subdirectories and .c Files) The management of dependencies and header files in a C++ library is an essential problem that, for many potential C++ developers, seriously limits the usefulness of the language. We have developed a scheme that ensures efficient inclusion of required header files while requiring minimal effort from the application developer. This scheme is not difficult to use, but it is rather intricate and takes some effort to establish. Once in place, however, maintenance and use of the library are greatly simplified. We will describe this organizational scheme in a later article. (see Managing C++ Libraries: Dependencies and Headers)
orr@cs.glasgow.ac.uk (Fraser Orr) (11/02/88)
In article <4959@thorin.cs.unc.edu> coggins@coggins.cs.unc.edu (Dr. James Coggins) writes: >The management of dependencies and header files in a C++ library is an >essential problem that, for many potential C++ developers, seriously >limits the usefulness of the language. We have developed a scheme >that ensures efficient inclusion of required header files while >requiring minimal effort from the application developer. This scheme >is not difficult to use, but it is rather intricate and takes some >effort to establish. Once in place, however, maintenance and use of >the library are greatly simplified. We will describe this I also have developed a scheme to simplify the management of header files (as part of a larger program managment scheme.) It is simple to use and set up. And after a short while becomes almost unnoticable. In essence each chunk of Code begins with a line that names that chunk and gives it a type. (The type of information contained in that chunk, class, type declerations etc) This is followed by a line explaining what other chunks are used. This is run through a preprocessor that inserts the appropriate includes and declarations. A quick example will illuminate . You type ... Class Queue Uses ItemType Class Queue { ItemType Data [100] ; public: . . . } ; And the declaration of ItemType is automatically inserted. It works by keeping a file of names and associated decalrations which is maintained from compile to compile. This (in my humble opinion) is what should have happened in the first place. I heard at a conference I was at recently, that the next version of C++ from AT&T is going to include type info in the .o files, and check inter module type infromation at link time. Does anyone know if this rumour is true? ==Fraser Orr ( Dept C.S., Univ. Glasgow, Glasgow, G12 8QQ, UK) UseNet: {uk}!cs.glasgow.ac.uk!orr JANET: orr@uk.ac.glasgow.cs ARPANet(preferred xAtlantic): orr%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk