Electronic Archaeology
Pages: 1, 2, 3, 4
Linux Cross Reference (lxr)
This system is used to provide a cross reference of the Linux Kernel as well as the Mozilla browser. It uses a web browser as a user interface.
The left image shows a code listing. If you select an identifier you are taken to a page listing at every place the identifier occurs. Clicking on one of the items here takes you to the location in the file.
One of the problems with this program is that you must have access to a web server to install this. Also don't attempt to install this program unless you understand Perl well. (It has some of the most complex and uncommented regular expressions I've ever seen.)
The C/C++ Pre-processor
It takes time to make a good mess. Programs start out simple. But then the code gets ported to a new platform. A few #ifdef directives are added to handle platform difference. But then marketing wants a new variant of the program. So more #ifdef directives are added.
As time goes on, more and more conditional compilation directives are added, resulting in more and more complex code. Many of these directives are for platforms or variants that haven't been used in years, but they still remain because no one knows how to take them out.
It soon becomes impossible to tell what's compiled and what's not. That's where the pre-processor comes in. By running the code through the pre-processor, you can tell what's really compiled.
There is a simple technique for making sure that your pre-processor results reflect your current compilation.
First, compile the code normally and redirect the output of make to
a log file:
$ make strange.o
g++ -g -DUNIX -DM8K -DPROD -DECHO -DSPEEDUP_CODE -c strange.cpp
Find the compilation command in the log file. Write it to a shell script.
Edit the script and change -c (and other flags) to -E (pre-processor
output).
Finally, run the shell script:
$ sh -x pre.sh
g++ -DUNIX -DM8K -DPROD -DECHO -DSPEEDUP_CODE -E strange.cpp > strange.pre
The following table illustrates the results:
#ifdef LOCATE_CALLS
char *save_block(char *block, int size,
char *file, int line)
#endif
#ifndef LOCATE_CALLS
char *save_block(char *block, int size)
#endif
{
#ifndef NATIVE_MALLOC
char *result;
#endif
#ifdef LOG_CALLS
log_message(file, line, "save_block(%p,
%d)", block, size);
#endif LOG_CALLS
#ifdef NATIVE_MALLOC
return (memcpy(malloc(size), block, size));
#endif
#ifdef SINGLE_BLOCK_ALLOC
result = find_memory(size);
result += sizeof(struct mem_header);
memcpy(result, block, size);
return (result);
#endif
#ifdef OOO_INTERFACE
#ifdef LOCATE_CALLS
return ((*alloc)(file, line, block, size));
#else
return ((*alloc)(block, size));
#endif
#endif
} |
# 1 "cpp_hell.cpp"
char *save_block(char *block, int size)
{
return (memcpy(malloc(size), block, size));
} |
Pre-processor and Vim
The Vim editor contains some nice commands that make it easy to view your source file alongside the pre-processor output.
Start by editing both files with the gvim by using the command:
gvim strange.cpp strange.pre
Set the scrollbind option (:set scrollbind).
Split windows vertically (:vsplit) and go to the next file (:next).
You now have two windows side by side, with the source file and the
pre-processed file. (If you need help with window navigation in
Vim, execute the command :help windows.

Source Navigator
The Source Navigator tool provides an integrated development environment. It provides a nice editor, a source browser, a class browser, and a cross reference.
But it's not perfect. Building the index is slow and the command interface is not the easiest to use. It also breaks on large, complex source packages.
I don't have much experience with this package. Every time I've tried it, the sources have been just too large and weird and have caused Source Navigator to crash.
Resources
O'Reilly & Associates recently released (December 2002) Practical C++ Programming, 2nd Edition.
Sample Chapter 26: Program Design, is available free online.
You can also look at the Table of Contents, the Index, and the Full Description of the book.
For more information, or to order the book, click here.
Steve Oualline wrote his first program when he was eleven. He has written almost a dozen books on programming and Linux software.
Return to the O'Reilly Network.
You must be logged in to the O'Reilly Network to post a talkback.
Showing messages 1 through 8 of 8.
-
another alternative to find/grep
2003-05-07 14:01:28 anonymous2 [Reply | View]
"find . -name \*.c -exec grep foo \;" is quite slow and cumbersome to type. "grep -r foo ." is GNU only and you can't restrict which files it sees. You can use "find . -name \*.c | xargs grep foo" to run almost as fast as the latter with the full expressive power of the former and xargs is a standard tool. Use xargs in any pipeline to invoke the command given as its argument using arguments taken from stdin. In this case, invoke grep foo with files produced by find.
-
Why they are called tags and not procedures in ViM
2003-05-04 21:34:51 anonymous2 [Reply | View]
> In programming they are called procedures. For
> some reason in Vim they are called tags.
This is because procedures are not the only things you can navigate using tags. You can use them on #defined constants, typedefs etc also.
Ashwin N
http://symonds.net/~ash/
-
vim
2003-05-03 09:22:22 dasper [Reply | View]
I'm a vim fan. I've used lots of programming editors, but gravitated to vi when I started working on many different platforms. I started using MKS vi on Windows several years ago, then discovered vim and switched to it. When I bought my iBook last year I started using vim on Mac OS X and recently, when Apple released its X11, I began using gvim in X Windows. It is very nice. One of the things I got from this article that I previously hadn't realized or used is the ability to pipe output from Unix commands directly into gvim. Beautiful.
-
Right but there is better
2003-04-30 16:40:14 anonymous2 [Reply | View]
Well written article. I'm using all the tools .... IF I can't use Slickedit.
Slickedit knows all the features written here and much more. They are well integrated, easy to use, easy to learn, controllable by both GUI and command line, very efficient, extendable, supports most Unices and others. I started using it for everyday electronic archaeology over 5 years ago and still find it far the most efficient to help the human bottlenecks.
Microsoft uses it to develop the core of its OS. Well over 64,000 files. Linux 2.4.20 kernel has not even 14,000 files.
-
Source Navigator
2003-04-30 16:08:48 hetzerrr [Reply | View]
I just discovered this tool in the last week, and have found it to be stable (on WIN32) and extremely helpful in developing a mental and/or visual model of large code bases.
-
Vim is an excellent tool
2003-04-30 09:57:22 anonymous2 [Reply | View]
I use Vim because I'm more productive.
One minor correction for the article...
The * command searches forward and
the # command searches backward.
-
Should have a different title
2003-04-30 05:21:58 anonymous2 [Reply | View]
after reading this article, it seems a more appropriate title would be 'tools of electronic archaeology'.
the raw ability to find references to functions and variables has little to do with the actual application of untangling a pile of spaghetthi.
it's like having a fork without the knowledge of how to eat.







