30.3. Executable-Code Tools

Tools for working with executable code are as rich as the tools for working with source code.

Code Creation

The tools described in this section help with code creation.

Compilers and Linkers

Compilers convert source code to executable code. Most programs are written to be compiled, although some are still interpreted.

A standard linker links one or more object files, which the compiler has generated from your source files, with the standard code needed to make an executable program. Linkers typically can link files from multiple languages, allowing you to choose the language that's most appropriate for each part of your program without your having to handle the integration details yourself.

An overlay linker helps you put 10 pounds in a five-pound sack by developing programs that execute in less memory than the total amount of space they consume. An overlay linker creates an executable file that loads only part of itself into memory at any one time, leaving the rest on a disk until it's needed.

Build Tools

The purpose of a build tool is to minimize the time needed to build a program using current versions of the program's source files. For each target file in your project, you specify the source files that the target file depends on and how to make it. Build tools also eliminate errors related to sources being in inconsistent states; the build tool ensures they are all brought to a consistent state. Common build tools include the make utility that's associated with UNIX and the ant tool that's used for Java programs.

Suppose you have a target file named userface.obj. In the make file, you indicate that to make userface.obj, you have to compile the file userface.cpp. You also indicate that userface.cpp depends on userface.h, stdlib.h, and project.h. The concept of "depends on" simply means that if userface.h, stdlib.h, or project.h changes, userface.cpp needs to be recompiled.

When you build your program, the make tool checks all the dependencies you've described and determines the files that need to be recompiled. If five of your 250 source files depend on data definitions in userface.h and it changes, make automatically recompiles the five files that depend on it. It doesn't recompile the 245 files that don't depend on userface.h. Using make or ant beats the alternatives of recompiling all 250 files or recompiling each file manually, forgetting one, and getting weird out-ofsynch errors. Overall, build tools like make or ant substantially improve the time and reliability of the average compile-link-run cycle.

Some groups have found interesting alternatives to dependency-checking tools like make. For example, the Microsoft Word group found that simply rebuilding all source files was faster than performing extensive dependency checking with make as long as the source files themselves were optimized (header file contents and so on). With this approach, the average developer's machine on the Word project could rebuild the entire Word executable several million lines of code in about 13 minutes.

Code Libraries

A good way to write high-quality code in a short amount of time is not to write it all but to find an open source version or buy it instead. You can find high-quality libraries in at least these areas:

• Container classes

• Credit card transaction services (e-commerce services)

• Cross-platform development tools. You might write code that executes in Microsoft Windows, Apple Macintosh, and the X Window System just by recompiling for each environment.

• Data compression tools

• Data types and algorithms

• Database operations and data-file manipulation tools

• Diagramming, graphing, and charting tools

• Imaging tools

• License managers

• Mathematical operations

• Networking and internet communications tools

• Report generators and report query builders

• Security and encryption tools

• Spreadsheet and grid tools

• Text and spelling tools

• Voice, phone, and fax tools

Code-Generation Wizards

If you can't find the code you want, how about getting someone else to write it instead? You don't have to put on your yellow plaid jacket and slip into a car salesman's patter to con someone else into writing your code. You can find tools that write code for you, and such tools are often integrated into IDEs.

Code-generating tools tend to focus on database applications, but that includes a lot of applications. Commonly available code generators write code for databases, user interfaces, and compilers. The code they generate is rarely as good as code generated by a human programmer, but many applications don't require handcrafted code. It's worth more to some users to have 10 working applications than to have one that works exceptionally well.

Code generators are also useful for making prototypes of production code. Using a code generator, you might be able to hack out a prototype in a few hours that demonstrates key aspects of a user interface or you might be able to experiment with various design approaches. It might take you several weeks to hand-code as much functionality. If you're just experimenting, why not do it in the cheapest possible way?

The common drawback of code generators is that they tend to generate code that's nearly unreadable. If you ever have to maintain such code, you can regret not writing it by hand in the first place.

Setup and Installation

Numerous vendors provide tools that support creation of setup programs. These tools typically support the creation of disks, CDs, or DVDs or installation over the Web. They check whether common library files already exist on the target installation machine, perform version checking, and so on.

Preprocessors

Preprocessors and preprocessor macro functions are useful for debugging because they make it easy to switch between development code and production code. During development, if you want to check memory fragmentation at the beginning of each routine, you can use a macro at the beginning of each routine. You might not want to leave the checks in production code, so for the production code you can redefine the macro so that it doesn't generate any code at all. For similar reasons, preprocessor macros are good for writing code that's targeted to be compiled in multiple environments for example, in both Windows and Linux.

Cross-Reference

For details on moving debugging aids in and out of the code, see "Plan to Remove Debugging Aids" in Section 8.6.

If you use a language with primitive control constructs, such as assembler, you can write a control-flow preprocessor to emulate the structured constructs of if-then-else and while loops in your language.

cc2e.com/3091

If your language doesn't have a preprocessor, you can use a standalone preprocessor as part of your build process. One readily available preprocessor is M4, available from http://www.gnu.org/software/m4/.

Debugging

These tools help in debugging:

Cross-Reference

These tools and their benefits are described in Section 23.5, "Debugging Tools Obvious and Not-So-Obvious."

• Compiler warning messages

• Test scaffolding

• Diff tools (for comparing different versions of source-code files)

• Execution profilers

• Trace monitors

• Interactive debuggers both software and hardware

Testing tools, discussed next, are related to debugging tools.

Testing

These features and tools can help you do effective testing:

Cross-Reference

These tools and their benefits are described in Section 22.5, "Test-Support Tools."

• Automated test frameworks like JUnit, NUnit, CppUnit, and so on

• Automated test generators

• Test-case record and playback utilities

• Coverage monitors (logic analyzers and execution profilers)

• Symbolic debuggers

• System perturbers (memory fillers, memory shakers, selective memory failers, memory-access checkers)

• Diff tools (for comparing data files, captured output, and screen images)

• Scaffolding

• Defect-injection tools

• Defect-tracking software

Code Tuning

These tools can help you fine-tune your code.

Execution Profilers

An execution profiler watches your code while it runs and tells you how many times each statement is executed or how much time the program spends on each statement or execution path. Profiling your code while it's running is like having a doctor press a stethoscope to your chest and tell you to cough. It gives you insight into how your program works, where the hot spots are, and where you should focus your code-tuning efforts.

Assembler Listings and Disassemblers

Some day you might want to look at the assembler code generated by your high-level language. Some high-level-language compilers generate assembler listings. Others don't, and you have to use a disassembler to re-create the assembler from the machine code that the compiler generates. Looking at the assembler code generated by your compiler shows you how efficiently your compiler translates high-level-language code into machine code. It can tell you why high-level code that looks fast runs slowly. In Chapter 26, "Code-Tuning Techniques," several of the benchmark results are counterintuitive. While benchmarking that code, I frequently referred to the assembler listings to better understand the results that didn't make sense in the high-level language.

If you're not comfortable with assembly language and you want an introduction, you won't find a better one than comparing each high-level-language statement you write to the assembler instructions generated by the compiler. A first exposure to assembler is often a loss of innocence. When you see how much code the compiler creates how much more than it needs to you'll never look at your compiler in quite the same way again.

Conversely, in some environments the compiler must generate extremely complex code. Studying the compiler output can foster an appreciation for just how much work would be required to program in a lower level language.