From: sdm@cs.brown.edu (Scott Meyers)
Subject: Re: C++ maintenance
Organization: Brown University Department of Computer Science
Distribution: na
Date: Tue, 26 Jan 1993 03:19:23 GMT

In article <harvey.728009429@regina> harvey@opl.com (Harvey Reed) writes:
| djb@geovision.gvc.com (Darren Burns) writes:
| >...
| >it does, but I'm not terribly familiar with the code.  In a member
| >function I see:
| 
| >int the_class::do_something ( )
| >{
| >...
| >    foo->xxx();
| >...
| >}
| 
| >Now, I'm browsing through this code and I'm thinking maybe the bug I'm
| >looking for is in xxx().  I want to take a look at it.  In order to know
| >which xxx to look at (since there may be many classes that have xxx), I
| >need to know what class foo is.  But foo could be a global variable,
| >a member of the_class, or a variable local to the function.  I have to
| >hunt all over the place just to find out where to look for xxx.

| Well, that can be a problem. One workaround for C++ (and maybe 
| other languages) is to use naming conventions.

Oh please.  If ever there were a job for a machine, looking up symbol
definitions is that job.  Another poster mentioned browsers, but some
browsers are not designed to answer the specific question that is put forth
here, which is "Where in *(&*&! is the function xxx declared?"

One approach to the problem is to build a database with information about
the program you're working on and to then add a database query interface to
your favorite editor so that you can say to your editor, "take me to where
xxx is declared," and your editor will promptly do so.  We built such a
system here at Brown University, using the XREFDB database that is part of
FIELD and adding a query interface to our favorite editor, which happens to
be Emacs.   You can read all about it in the following paper, which, rumor
has it, just appeared in the 12/92 issue of Transactions on Software
Engineering:

  @ARTICLE{maintaining-oop,
          AUTHOR = {Moises Lejter and Scott Meyers and Steven P. Reiss},
          TITLE = {{Support for Maintaining Object-Oriented Programs}},
          JOURNAL = tse,
          YEAR = {1992},
          VOLUME = {18},
          NUMBER = {12},
          MONTH = dec,
          NOTE = {Also available as Brown University Computer Science
                  Department Technical Report No. CS-91-52, August 1991.  An
                  earlier version of this paper appeared in the
                  \I{Proceedings of the 1991 Conference on Software
                  Maintenance} (CSM '91), October 1991.  This paper is
                  largely drawn from two other papers~\cite{sooppa,xrefdb}.}
  }

Both FIELD and the Emacs interface are publicly available, but before you
get too excited, let me tell you that we build prototypes here, not
products, and the system we implemented is slow.  Really slow.  Really
really really slow.  Honest.  Also, the database has to be rebuilt each
time the source code is changed, which tends to be pretty often during
development (ahem), so the current implementation is not particularly
practical.

I feel compelled to point out that a fundamental problem that is overcome
by neither naming conventions nor our query-based approach is that of
statically determining the possible bindings of dynamically bound
functions.  That is, if xxx is a virtual function, it doesn't necessarily
do a lot of good to know the static type of foo, because there may be a
googol of classes inheriting from foo's class, each of which redefines xxx,
and there is no easy way to determine which definition is the one you're
looking for.  Some minor assistance is offered by cbrowse, the FIELD class
browser, which will highlight all classes that redefine a virtual function
when you click on that function.  The depth of your depression then tends
to be proportional to the number of things that light up on your screen :-)

I'd be interested in hearing how other environments help developers find
the answer to the question the original poster raised, especially for the
case where xxx is virtual.  

Having mentioned FIELD twice, and having already run on at the keyboard
this long, I'll append here the standard FIELD availability blurb that I
post from time to time:

  The FIELD programming environment, an extensive set of tools for
  programming in C++, C, and Pascal, is available at no cost from Brown
  University.  Specialized C++ tools include a class browser (cbrowse) and a
  debugger that runs on top of dbx or gdb.  Both Gnu and AT&T compilers are
  supported.  FIELD uses the tools of the Brown Workstation Environment
  (BWE), which in turn runs on top of X11.

  If you'd like more information about FIELD, e.g., what it is, what it can
  do, what systems it runs on, etc., send your questions to bwe@cs.brown.edu.
  This is the address to which ALL technical correspondence should be sent.

  If you'd like to get a copy of FIELD, we have made it available via
  "semi-anonymous" ftp.  Send your name, business address, phone and fax
  number to brusd@cs.brown.edu and we will send you instructions on how to
  get FIELD.  This address is for distribution information ONLY.
  Alternatively, you may fax a request to Kathleen Kirman at 401/863-7657,
  but again, this is for distribution information ONLY.  (If you don't have
  FTP access, it is possible to get tape copy of the software, but there is a
  charge for that form of distribution.)

  If you'd like to read about FIELD before you get it, consider these
  articles:

    Steven P. Reiss, "Connecting Tools using Message Passing in the FIELD
    Program Development Environment," IEEE Software, July 1990, pp. 57-67.

    Steven P. Reiss, "Interacting with the FIELD Environment," Software:
    Practice and Experience, 20:S1, June 1990, pp. 89-115.

    Steven P. Reiss and Scott Meyers, "FIELD Support for C++," USENIX C++
    Conference Proceedings, April 1990, pp. 293-299.

    Moises Lejter and Scott Meyers and Steven P. Reiss, "Support for
    Maintaining  Object-Oriented Programs," Proceedings of the Conference on
    Software Maintenance, October 1991, pp. 171-178.

  Unfortunately, electronic copies of these papers are not available.

Scott

-------------------------------------------------------------------------------
What do you say to a convicted felon in Providence?  "Hello, Mr. Mayor."
Newsgroups: comp.lang.c++