sdm@cs.brown.edu (Scott Meyers) (10/15/89)
Some time ago I asked people to send me information on C++ development
tools that they knew about. The results were quite disappointing. I got a
lot of information about libraries that are available, but virtually
nothing about any other kinds of tools. Now libraries are certainly
important, but are they really the only kinds of tools that C++ developers
need?
This time, I'd like to pose a slightly different question. What are the
tools that should be part of an ideal C++ development environment? I'm
concerned here with C++-specific tools -- I don't care about what kind of
workstation they run on, so you can feel free to posit the existence of any
kind of hardware you like. For example, if you can think of a useful tool
that would require real-time interactive 3D color graphics with shading and
hidden-line removal, then just assume you're working on something that can
do that (e.g., something from SGI) and ignore the fact that it wouldn't
work on a PC.
To get the creative juices flowing, here's part of the product annoucement
for Objectworks for C++:
Objectworks brings three essential object-oriented programming
tools to the C++ system: incremental compiling and linking,
source-level debugging and source code browsing. The incremental
compiler/linker involves the C++ translator and host compiler and links
the modified functions. Use of the host compiler ensures identical
behavior of programs during the development process and at the time of
application delivery. The source-level debugger allows programmers to
interact with the execution state of a program and to inspect and
change the values of variables. The source code browser of Objectworks
for C++ enables programmers to view the class hierarchy and file
structure of application code in a graphical way. Programmers can
query the system, dynamically searching for a function's implementors
and callers. Additionally, the browser allows programmers to search
for references to data types or to filter the search on the basis of
C++ private, protected or public interfaces. Additionally, Objectworks
for C++ includes a file browser, providing a graphical interface to the
Unix operating system and file system that simplifies the management of
files and directories. This interface is called the Unix Navigator[TM].
Please post responses to the net; perhaps we can collaborate on a
description of the ideal pie-in-the-sky money-is-no-object C++ programming
environment. Then maybe somebody will be inspired to start implementing
it.
Scott Meyers
Brown University
sdm@cs.brown.edujohnson@p.cs.uiuc.edu (10/17/89)
ObjectWorks for C++ brings to C++ the programming environment of Smalltalk. Actually, it is not quite as fast as that of Smalltalk, and it doesn't catch all the run-time errors like Smalltalk does, but it is pretty close. I predict that C++ programmers will like it a lot. Folks, Smalltalk is 10 years old! ObjectWorks is just catching up with 10 year old technology. It is true that there really aren't any programming environments much nicer than Smalltalk, but that is really an indictment on the CS community. One of the reasons has been that people have spent the last 10 years trying to mimic Smalltalk instead of trying to go beyond Smalltalk. People try to extend the Smalltalk programming environment model to handle programming-in-the-many rather than to think of radically different ways of programming. Two of the systems that should be studied carefully are NeXTs Application Builder and Randy Smith's Alternate Reality Kit. Both of these systems fit in very well with the OO emphasis on reusable components. Both could make it possible for nonprogrammers to play a big role in customizing systems. What I would like to see is a Hypercard-like system where the user can easily add new kinds of objects at the bottom but could program at the top-level using a direct manipulation interface. This would be hard to do with C++, but is probably possible. Browsers are very good when your library is small, like with 500 or fewer classes. This is plenty large enough for most programmers, since a Unix kernel, a compiler, an accounting system, etc. are all smaller than this. However, I don't think that browsers will work well on really big systems. Moreoever, browsers work best when you are examining a system with which you are familiar. They are not as good when you are trying to find a component in a libarary that somebody else created. We need to have better tools for managing very large systems, especially large databases of components that we only rarely examine. My guess is that techniques developed by the information retrieval people will be useful here. A problem that will prove to be important in the future is that of managing change. It is already an important problem, but people don't seem to realize it. Libraries are not static--they change as we learn from experience how we should have done them in the first place. If you change a library then your customers have to rewrite programs that use the library. If you don't change the library then it eventually becomes obsolete, and your customers complain that newer libraries have much better features and are much easier to use. This has already happened to systems like MacApp (i.e. they finally made a big change) and is an old problem in Smalltalk. C++ programmers haven't seen this problem yet because none of the libraries have been around long enough, but they will! This problem is one of my research areas at the moment, and with a little luck we will have it figured out before the problem becomes really severe. Ralph Johnson - Univeristy of Illinois at Urbana-Champaign
metz@iam.unibe.ch (Igor Metz) (10/20/89)
In article <77300035@p.cs.uiuc.edu> johnson@p.cs.uiuc.edu writes: >[...] >Two of the systems that should be studied carefully are NeXTs Application >Builder and Randy Smith's Alternate Reality Kit. [...] What is "Randy Smith's Alternate Reality Kit"? -- Igor Metz X400: metz@iam.unibe.ch Institut fuer Informatik ARPA: metz%iam.unibe.ch@relay.cs.net und angewandte Mathematik UUCP: ..!uunet!mcvax!iam.unibe.ch!metz
880716a@aucs.uucp (Dave Astels) (06/07/90)
Are there any specifically C++ documentation tools available yet? I refer to tools such as cflow, cxref, indent, etc. -- - Dave Astels Internet: 880716a@AcadiaU.CA Bitnet: 880716a@Acadia