NetNews Usenet Archive 1992 #27

home *** CD-ROM | disk | FTP | other *** search

/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / cplus / 16486 < prev next >

Wrap

Text File | 1992-11-17 | 25.4 KB | 682 lines

Newsgroups: comp.lang.c++ Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!dptg!ucs!skdutta From: skdutta@ucs.att.com (Saumen Dutta) Subject: C++ Product List - Version 2.04 - Part 8/8 Message-ID: <1992Nov18.023213.916@ucs.att.com> Organization: AT&T Universal Card Services, Jacksonville FL Date: Wed, 18 Nov 1992 02:32:13 GMT Lines: 672 5. Tools _ _____ In this section we will cover C++ tools which helps developing C++ and other programs. Some of these are already being covered in the previous chapters and are omitted here. 5.1. Interviews Drawing Editor _ _ __________ _______ ______ + It is available via anonymous ftp from interviews.stanford.edu + On line drawing tool capable of interactive line draw- ing and filling. It creates a postscript file. Files created by Idraw can also be imported. It supports split view, grouping, ungrouping etc. 5.2. Interviews Interface Builder _ _ __________ _________ _______ + It is available via anonymous ftp from interviews.stanford.edu + Interactive Interface building tool which creates C++ code which can be compiled with other Libraries sup- plied with Interviews. 5.3. FIELD C++/C/Pascal Development Environment _ _ _____ _ _ ______ ___________ ___________ + It is available from Brown University. Instructions for "semi-anonymous" ftp can be obtained by sending name, business address, phone and fax number to brusd@cs.brown.edu. Alternatively, a request may be faxed to Kathleen Kirman at (401)863-7657. + FIELD programming environment provides an extensive set of tools for programming in C++, C and Pascal. FIELD uses the tools of the Brown Workstation Environ- ment (BWE), which in turn runs on top of X11. Various utility tools provided by FIELD programming environment includes the following: - C++ class browser (cbrowse). This is more power- full when compared to iclass provided by Inter- Views. It offers graphical as well as textual output. The drawbacks are that it is much more slower than iclass, and it needs a lot more memory. - debugger. The debugger in this environment runs on top of dbx or gdb. It supports both GNU and AT&T compilers. For more information, refer to the following papers 1. Steven P. Reiss, "Connecting Tools using Message Passing in the FIELD Program Development Environ- ment", IEEE Software, July 1990, pp 57-67. 2. Steven P. Reiss, "Interacting with the FIELD Environment", Software: Practice and Experience, 20:S1, June 1990, pp. 89-115. 3. Steven P. Reiss and Scott Meyers, "FIELD Support for C++", USENIX C++ Conference Proceedings, April 1990, pp. 293-299. + Information provided by Scott Meyers (sdm@cs.brown.edu) 5.4. MTS (Memory Tuning System) _ _ ___ ______ ______ ______ + Platform: Unknown + Commercial product marketed by : NewCode Technology Incorporated 200 Boston Avenue Medford, MA 02155 Tel: (617) 396-3009 Fax: (617) 395-9452 + MTS includes a malloc interface that guarantees quick installation. Its use does not require any reprogram- ming. It includes a report facility that details the different types and sizes of a programs memory usage. Using the report, MTS can be tuned for a typical pro- gram run. For object oriented programs, this mechanism provides a memory management scheme for each class of object in use. Using MTS, the developer is relieved of the need to write specific code to optimize memory access. NewCode's MTS employs a hierarchy of memory management schemes that are designed to fulfill the dual purpose of minimizing paging activity while providing very fast allocation and reuse of many small and medium size objects. As an in memory allocator, MTS is typically three times as fast as the standard malloc package. More importantly, its contribution to minimizing paging overhead can lead to dramatic improvements in overall program performance. + Information provided by: Ze'ev Mehler ( zeev%cybvax0@uunet.uu.net ) 5.5. Cback _ _ _____ + Platform: Works with the Cfront output. Tested with SUN3, SPARC, RS6000, DEC RISC, Interactive Unix and SCO Unix/Xenix on 386/486. + Commercial product marketed by : NewCode Technology Incorporated 200 Boston Avenue Medford, MA 02155 Tel: (617) 396-3009 Fax: (617) 395-9452 + cback is a companion product to cfront based C++ trans- lators. It processes cfront C output and creates easy to read, smaller, faster and portable C code. + Information provided by: Ze'ev Mehler ( zeev%cybvax0@uunet.uu.net ) 5.5.1. Introduction _ _ _ ____________ cback is a fast, rule driven, C to C translator that in addition to producing C code that is easy to read and under- stand, CAREFULLY eliminates unreferenced declarations, unreferenced static functions, redundant assignments to vptr and performs many other cfront specific cleanups. Each of cback's rules can be turned on or off to suit a variety of different needs. cback does a thorough job of simplifying cfront's compli- cated statements and expressions. Even complex cfront out- put that your local C compiler might reject, will compile without fault. cback's output is maintainable and will readily cross compile to systems that currently do not sup- port C++. cback typically eliminates 70% of cfront's C code output. While debugging, cback will shrink the overall size of a typical application by 40%. Thus during development your binary files as well as link and debugger load times will be substantially smaller and faster. When compiling with optim- ization, cback can also produce significant code size reduc- tions. cback will fit seamlessly into your compiling and debugging environment. Our supplied shell script will call both cfront and cback and will work with your current make files. In addition, cback will recreate appropriate line numbers and for Sun's cfront it will filter .stab statements for use with dbx. 5.5.2. Netcomments _ _ _ ___________ From: Dale Lutz (dal@mdavcr.mda.ca) on comp.lang.c++ We used cback on a rather large development (300,000 lines of C++) and found it to be extremely worthwhile. On the average, the size of executables and object files after using cback was one half the pre-cback size. Link times were also about 1/2 what they were before. Of course, your mileage may vary. In our case, you can guess it didn't take too long to repay our original investment. We were using SUN C++ 2.0 on SUN SPARCStations. Dale (Not an MDA spokesman, and not affliated with the cback maker in any way. Its just a great product I want other people to know about). 5.6. Purify _ _ ______ + Platform: SPARC + Commercial product marketed by : Pure Software 1309 S. Mary Avenue Sunnyvale, CA 94087 Phone: (408) 720-1600 e-mail: info@pure.com + Price is $2750 for a floating license, volume discount available. Free two-week trial evaluation of Purify, which can be arranged through email. + Purify enables C and C++ developers to produce more reliable software by detecting and pinpointing the leading cause of unexpected system failures-run-time errors, both memory access errors and memory leaks. It makes error detection and correction easier, faster, and more comprehensive. Purify performs instruction- level checking on all of the code, including third- party libraries, while imposing minimal run-time over- head, so it is practical to use on large applications. By preventing memory leaks, Purify improves performance, particularly for longer running applica- tions. Purify's run-time error detection is particularly valu- able to C++ developers, as these programs typically make extensive and complex use of dynamic memory. Purify was reviewed in the September issue of IEEE Software and was also chosen for an Outstanding Product Award by Unix Review (December 1992). + Information provided by: Barbara Kay ( bkay@pure.com ) 5.7. Sniff _ _ _____ + Written by: Walter R. Bischofberger UBILAB (UBS Informatics Laboratory) Union Bank of Switzerland Bahnhofstrasse 45 CH-8021 Zurich/Switzerland Phone: (0041) 01 236 31 83 (direct) Fax: (0041) 01 236 46 71 (direct) Email: bischi@ZH010.ubs.ubs.arcom.ch may be ftp'ed from iamsun.unibe.ch (130.92.64.10) /pub/Sniff1.6 or C++/Sniff1.6 directory self.stanford.edu (36.22.0.201 or 36.22.0.41) /pub/sniff directory takeFive Software is expected to market this software in near future (this may be the last public domain release of Sniff). If you do not have ftp access, send $80 to takeFive Software GesmbH Jakob-Haringer-Str. 8 5020 Salzburg Austria Tel. 0043 662 45 79 15 Fax. 0043 662 45 79 15 6 email: info@takeFive.co.at They will send you a quarter inch tape (other media on request) and the printed documentation. For $20 you will get the printed documentation only. + The newest public domain release (1.6) runs on SPARCs- tations only. It requires OS 4.1.2 (it is not tested under 4.1.1) and it runs under Open Windows and X11 (olwm, mwm, and twm window managers) as well as under SunView. + Sniff is a C++/C programming environment providing browsing, cross- referencing, design visualization, documentation, and editing support. It delegates compi- lation and debugging to any C++ compiler and debugger of choice. The main goal in developing Sniff was to create an efficient portable C++ programming environment which makes it possible to edit and browse large software systems textually and graphically. Much emphasis was laid on runtime and memory efficiency and on a comfort- able user interface. + Information provided by Walter R. Bischofberger (bischi@ZH010.ubs.ubs.arcom.ch) Most of the information given below is written by the author and is copied from a README file from Sniff distribu- tion. 5.7.1. History and Future _ _ _ _______ ___ ______ Sniff was developed in the research laboratory of the Union Bank of Switzerland (UBS) where it has been used on its own development for about one year. Two public domain beta releases of Sniff have been available for some months. These releases were applied for professional software development at several places. This is the announcement of release 1.6. Version 1.6 is the last public domain release. It has lost the beta. Now that Sniff is almost finished I want to free myself from the time consuming porting, support, and maintenance chore. For this reason UBS cooperates with takeFive - a Salzburg based software house - which will produce the first commercial release of Sniff until end of year. A prere- quisite for this cooperation is that universities get further commercial releases of Sniff almost for free and research laboratories will get Sniff at a fraction of the commercial price. 5.7.2. Main Tools _ _ _ ____ _____ A running version of Sniff consists of two operating system processes, the information extractor and the program- ming environment itself. The information extractor can run locally or on any node of a network. Its task is to extract information about definitions and declarations from the source code. The programming environment consists of a number of tools which are organized around a kernel consisting of the symbol table and the project manager. Both the symbol table and the project manager organize information in main storage, which is used by browsers and editors. The symbol table manages the information about symbol definitions and declarations and the project manager manages the information about open projects such as the source files they consist of and various attributes. 5.7.3. Information Extraction _ _ _ ___________ __________ Sniff's information extractor is a fuzzy C++ parser. This means that it understands enough about C and C++ to extract the information of interest without having to under- stand C++ completely. This approach makes it possible to parse every file only once without including header files and expanding macros. Not expanding macros is somewhat controversially because it could result in a loss of information if macros are used to change C++ syntax or semantics. Experience shows that this is no problem. Until now no user of Sniff has informed us about macro expansion problems. Not expanding macros means that the symbolic information corresponds exactly to the locally visible source code. This is fre- quently an advantage, for example, when macros are used to put unique prefixes in front of all class names. Sniff's information extractor extracts information about declarations and definitions of C++ language elements and macros. It does not extract information about the usage of symbols. This information is extracted on the fly. 5.7.4. Information Updating _ _ _ ___________ ________ If the source code of a project is edited the informa- tion about the location of the affected symbols is updated immediately. On saving a file its symbolic information is extracted anew and all browsing tools are updated. A user, therefore, works always with symbol based tools presenting him information that correctly mirrors the source code without ever having to bother about the effects of his changes. Sniff can not know when a source file was changed with another tool while its symbolic information was loaded. In this case the developer has to tell Sniff to update its sym- bol table. 5.7.5. Project Concept _ _ _ _______ _______ To start working with Sniff a developer has to define a project. I.e., the source files it contains and eventually a set of subprojects which can be shared among projects. A subproject is a complete project on its own. A typical project structure for a program building on a class library is to have a root project containing the pro- ject specific source files an to load the library project as subproject. Library projects are frequently trees of pro- jects themselves. Whenever a project is opened or when a file or a sub- project is loaded into the current project its source code is analyzed and the information about the symbols defined therein is stored in Sniff's symbol table. 5.7.6. Browsers and Editors _ _ _ ________ ___ _______ Once a new project is defined with the Project Editor or an existing project is opened it can be browsed and edited in different ways. + The Symbol Browser can be used to gain an overview about which symbols are defined in the source code or it displays the results of queries sent from other tools such as which symbols exist, the names of which match "X". + The Class Browser can be used to browse through the locally defined and inherited members of a class. + The Hierarchy Browser can be used to display the class graph and to visualize queries such as "mark all classes declaring method X". + The Retriever can be used to obtain information about where a certain symbol is used in the source code (i.e., cross reference information). The Retriever is a text search based tool. It makes it possible to extract all occurrences of strings matching the name of a sym- bol (or any regular expression) in a set of projects. The matches can then be further restricted with seman- tic filters. The Retriever provides therefore a much more powerful query facility than conventional cross referencing tools. + Sniff's comfortable mouse driven WYSIWYG Editor pro- vides several kinds of browsing support and it automat- ically highlights structurally important information such as class names, method names, and comments. Once a source file was modified it is possible to trigger its compilation from the editor and to mark the source lines where the compiler found syntax errors. The current version of Sniff does not provide an emacs interface. Because of the flood of requests we will provide emacs support with one of the next versions. 5.7.7. Efficiency _ _ _ __________ The loading of a project with 100,000 lines of code takes on a SPARCstation2 about 20 Seconds. Sniff needs with 100,000 lines of code loaded between 5 and 8 MB main storage (depending on how many tools are open). For every further 100,000 lines of code 3 to 4 MB are needed. For a project with 100,000 lines of code Symbolic queries (e.g., show all classes the names of which contain a certain string) can be answered in less than a second. Cross reference queries based on text search are answered in less than three second (once Sniff's internal cache is loaded). The most frequent cross reference queries are even answered in less than a second. 5.7.8. Acknowledgements _ _ _ ________________ My sincere thanks go to the Union Bank of Switzerland that gave me the freedom and founding which made it possible to develop Sniff and to distribute it in the public domain. The development of Sniff would not have been possible without the ET++ application framework and the support of its developers Erich Gamma and Andre Weinand. A good user interface has to grow. Thanks to all my colleagues who have been working with Sniff for several months giving me the feedback I needed. 5.7.9. References _ _ _ __________ Sniff is already used for large scale software develop- ment at several locations. For example: At UBS a team of twelve software developers switched within two days from their commercially available program- ming environment to the first public domain release of Sniff. They are working on a large portfolio management sys- tem written in C++ which interfaces with a relational data- base system. At MacDonald Dettwiler and Associates, a commercial software house, seven developers are using Sniff on software systems with up to 250,000 lines of source code and they are happy with Sniff's responsiveness and user interface. 6. Products _ ________ This section will discuss various c++ products. It will also cover some of the c++ products which could not be put into the previous three categories. 6.1. uC++ _ _ __ + may be ftp'ed from watmsg.uwaterloo.ca (129.97.141.9) pub/uSystem/u++-3.4.4.tar.Z + uC++ runs on the following processors: M68K series, NS32K series, VAX, MIPS, Intel 386, Sparc, and the fol- lowing UNIX operating systems: - generic BSD 4.3 - Sun OS 4.x - Tahoe BSD 4.3 - Ultrix 3.x/4.x - DYNIX uC++ requires at least GNU C++ 2.2. uC++ will NOT com- pile using other compilers. To run multiprocessor on a Sequent GNU C++ must use the Sequent assembler and loader. + Augments C++ to allow control flow for light-weight concurrency on uniprocessor and multiprocessing on parallel processor. + Information provided by Rick Stroobosscher (rastroob@plg.uwaterloo.ca) Most of the information given below is written by the author and most of it is copied verbatim from a posting in comp.lang.c++. 6.1.1. Introduction _ _ _ ____________ We are pleased to announce, to any interested parties, the availability of Version 3.4.4 of uC++ (pronounced micro-C++). uC++ extends the C++ programming language in somewhat the same way that C++ extends the C programming language. The extensions introduce new objects that augment the existing set of control flow facilities and provide for light-weight concurrency on uniprocessor and parallel execu- tion on multiprocessor computers running the UNIX operating system. uC++ is not another thread package built on top of C++, but a comprehensive set of language extensions that integrate the notions of coroutine, mutual exclusion and concurrent execution into the language. 6.1.2. Features _ _ _ ________ 1. The uC++ translator may fail when given very bad syntax errors. The error recovery facilities of the transla- tor will be updated in version 4. Also, the translator is vulnerable to programs that use the same names for types and routines. Beware of this vulnerability. It may show up in very subtle errors. 2. The "inline" version of the runtime environment is not working in this release, so that performance is signi- ficantly slower than it can be. When the "inline" ver- sion is working, performance is comparable to any light- weight tasking system. 3. The only multiprocessor computer supported in this release is the Sequent Symmetry. Ports to more vendor/machines will appear shortly. 6.1.3. Requirements to run uC++ _ _ _ ____________ __ ___ __ uC++ requires at least version 3.8 of dmake, which is available by anonymous ftp from the following location (remember to set your ftp mode to binary): watmsg.uwaterloo.ca (129.97.141.9) pub/dmake/dmake38.tar.Z Execute the following command to unpack the source: % zcat dmake38.tar.Z | tar -xf - To build dmake, edit the variables in file ./1/startup.h. The variable MAKESTARTUP must specify the location of the startup.mk file, which contains all the implicit recipes. This file is placed at the top level of the source directory after dmake is built. If dmake is not being installed in a public location, set the value of MAK- ESTARTUP to dmake-source-path/startup.mk. After setting the MAKESTARTUP variable, execute the command make in directory dmake to determine what configurations are available. A list of possible configurations will be printed. Once dmake is built, add the executable to your command path. The current version of uC++ can be obtained by anonymous ftp from the following location (remember to set your ftp mode to binary): watmsg.uwaterloo.ca (129.97.141.9) pub/uSystem/u++- 3.4.4.tar.Z Execute the following command to unpack the source: % zcat u++-3.4.4.tar.Z | tar -xf - To build uC++, edit the variables in file ./Makefile. The variable ROOT must specify the current location of the uC++ source (the path to the directory that contains the source). The variable BINDIR specifies the location where the u++ executable and other executables needed for compila- tion are placed. The LIBDIR variable specifies the location for the u++ runtime libraries. Both BINDIR and LIBDIR have default values. After setting at least the ROOT variable, execute the command dmake in this directory to determine what configurations are available. A list of possible con- figurations will be printed. After installation is complete, there will be a number of executables created in the BINDIR location. Add this directory to your command path to access the compilation command u++, or move the u++ executable itself to a direc- tory in your command path. Do not move the other execut- ables in BINDIR, as the u++ executable references these exe- cutables and the runtime library via hard coded path names set at installation time. A postscript version of the uC++ reference manual is available in the same ftp directory as u++-3.4.4.tar.Z, called u++-3.4.4.ps. It contains a copy of the uC++ docu- mentation that has been formatted for 8.5x11 paper. This file has been made available because some people have had problems LaTeXing the documentation that comes with the uC++ distribution. Normally, it is unnecessary to retrieve this file as uC++ comes with the latex source for the reference manual. 6.1.4. References _ _ _ __________ There is a Software-Practice and Experience paper about uC++ Version 2.0 in the Feb 1992 issue. Note, there have been many changes from version 2 to 3, and there will be more changes from version 3 to 4. uC++ is being used daily to build highly concurrent access methods for persistent file structures (databases) here at Waterloo. 6.1.5. Future Enhancements _ _ _ ______ ____________ What's coming in uC++ Version 4: - inline version of kernel - visualization of concurrent execution - multiprocessor ports to SGI, Encore - uWait and uSignal as members of uCondition - port to IBM 6000 - task priorities - exception handling - improve translator, make more robust - time out on I/O calls We hope to have some of this done by the end of the year.