Advanced C 1992

Do not confuse the bitwise operators with the logical operators. The misuse of these operators can cause problems that are difficult to repair, such as those in the following program fragment:

//Using a logical AND:

if(x && y)

{

//With x == 1, and y == 2, this will ALWAYS be TRUE.

}

//Using a bitwise AND:

if (x & y)

{

// With x == 1, and y == 2, this will NEVER be TRUE.

}

Why does the bitwise test fail in this fragment? The answer is easy, but only if you look at the bits themselves. The bit pattern for x is 0000 0001, and the bit pattern for y is 0000 00010. Doing a bitwise AND shows the following:

0000 0001 & 0000 0010 = 0000 0000

Practice is one of the best teachers—practice using these operators to get a better feel for how they work. The following section discusses the use of these operators, including some example code fragments.

Bit Fields

A bit field is a data object being accessed at the bit level. These fields, which may be only one bit long, have for each bit a defined meaning that may or may not be related. A good programming practice is to make all the bits in a single bit field variable-related so that management of the bit field is easier. When you are using ANSI C, you generally can have a maximum of 16 bits in a bit-mapped variable. There are two ways to use bit fields:

155

Part I • Honing Your C Skills

1.Assign a meaning to each of the bits of any integer variable.

2.With a structure, you may create a bit field that is any length (to a maximum of 16 bits).

Let’s look first at user-defined bit fields. When you declare an integer variable, such as the following:

unsigned short int nFlag = 0;

the compiler allocates a 16-bit short integer and initializes it to zero. This example is less than meaningful for bit flags. To harness the power of a bit flag, you have to define each bit position and be able to test, set, and reset each bit without regard to the other bits. You know that you have 16 bits to work with, but you don’t know how to address them. This process isn’t as difficult as it might seem, because each bit has a logical value, and working with these values is easy.

Figure 5.8 shows the bits in the variable. You can easily determine (and assign) a meaningful flag for each of these bits, such as shown.

Figure 5.8. Bit values in a 16-bit integer.

Figure 5.8 shows that you use the value 4 to access the third bit from the right. Assume that if this bit is set, it tells you the user has a middle name, and if it is not set, the user doesn’t have a middle name. You first make a defined identifier so that your program is manageable:

#define MIDDLE_NAME 0x04

156

You use the hex value because it’s easiest to remember and use. The decimal equivalents are not that usable. Assign the first bit from the left to tell you that the user’s middle name is just an initial:

#define MIDDLE_INITIAL 0x80

Now that you have some defines, let’s look at how to use them. First, you can clear all flags in the flag variable nFlag by simply assigning a zero to it:

nFlag = 0;

To set the flag so that you know that the user has a middle name, you can use the following line:

nFlag |= MIDDLE_NAME;

This statement uses one of C’s bit operators. These operators seldom are used by most programmers, primarily because they are not well understood. This is a shame because they make management of logical information much easier.

Next, suppose that the person’s middle name is only an initial. You set both the MIDDLE_NAME flag and the MIDDLE_INITIAL flag. You can use one assignment or combine both:

nFlag |= (MIDDLE_NAME | MIDDLE_INITIAL);

This statement could have been written as

nFlag = (MIDDLE_NAME | MIDDLE_INITIAL | nFlag);

If the flag bits were already set for some reason, they don’t change. After they are set, performing a bitwise OR on them doesn’t change their state.

Now assume that you set the middle-name flag, but later you must change it to indicate that there is no middle name (or initial). Because the OR only sets (and doesn’t reset), you have to do something different:

nFlag &= (~MIDDLE_NAME & ~MIDDLE_INITIAL);

This statement introduces both the one’s complement operator ~ and the bitwise AND operator &. You have used the ONES COMPLEMENT operator to invert the identifier’s bits. For example, if the identifier’s bit pattern (as MIDDLE_NAME’s) is

0000 0100

the result of the ~ is

1111 1011

157

Part I • Honing Your C Skills

This bit flag, when it is combined using the bitwise &, enables you to turn off a bit in the nFlags variable. This effect is important because setting and resetting the bits is a common operation.

Finally, you must test bits. You want to test only those bits that are significant for whatever we are testing. For example, to see whether there is a middle name (the MIDDLE_NAME flag is set), you can use the following test:

if ((nFlag & MIDDLE_NAME))

In this test, several things are important. You must be careful not to use the logical AND operator (&&) when you intend to use the bitwise one. Also, you should use parentheses around each bitwise operation so that the order of precedence is clear. In the preceding test, the expression yields a nonzero value if the bit is set, or a zero if it is not. You can test two bits at one time using either

if ((nFlag & (MIDDLE_NAME | MIDDLE_INITIAL))

or

if ((nFlag & MIDDLE_NAME) && (nFlag & MIDDLE_INITIAL))

Because either expression is correct, which one you use is probably more a matter of programming style rather than efficiency. Just make sure that you are clear about the order in which the expression is evaluated; when in doubt, use parentheses.

Summary

In this chapter, you learned about decimal, hex, binary, and octal notation. You learned also about bit field usage.

•Decimal (base 10) is the number base we use in everyday life.

•Hex (base 16) most commonly is used by programmers in writing software. Some programmers can do hex addition and subtraction without the aid of a calculator.

•Binary (base 2) is the only base the CPU understands directly. All other number systems must be converted to binary for the CPU’s use.

158

•Octal, originally developed for DEC’s PDP-8 computers, seldom is used by today’s programmers, primarily because octal worked best with 12-bit-word computers.

•C supports six bitwise operators, enabling direct manipulation of bits by the programmer.

•Using bit fields, programmers can store much information by using individual bits.

159

SeparateCompilationCand Linking CC C C

C6C C

6 C C C

C C C

C C C

Separate Compilation

and Linking

Not all programs are as simple as the examples in this book. Rarely do you write a significant program that has only a single source file; if you do, it usually is too large to be maintained easily. Whether your program is huge, with hundreds of thousands of lines, or is a smaller one, with only a few thousand lines of code, you can benefit from using separate source files.

Some of the information in this chapter is based on Microsoft’s tools, such as its MAKE utility and the LIB program. If you are not using Microsoft’s products or are not even using a PC, much of the discussion in this chapter will be very helpful because it is information that is new to you.

161

Part I • Honing Your C Skills

Compiling and Linking Multiple Source Files

There are a number of reasons to have more than one source file. The most important reason is to help keep your program’s source organized. Without this organization, as the program grows larger, it becomes increasingly more difficult to maintain.

Because there are few rules regarding the subdivision of source code between files, how do you determine what to put in each file? First and foremost, the majority of the programs written don’t start out large. Most software developers create a shell for their programs (using the main() function) and then build the user interface and the program’s functionality using calls from main(). This process allows the developer to test and debug small parts of the program with the hope of not creating new problems for other parts of the program.

Prototyping is a technique for writing larger (and smaller) programs. Don’t confuse this use of prototyping with C’s use of it. Prototyping a program requires that you do (and have) a number of things, including the following:

1.Establish the program’s basic functionality. You must do this by working with the program’s final users.

2.Select an operating environment—whether it’s a standard character-based application (becoming increasingly rare) or a graphical user interface (GUI) Windows-based program such as Microsoft Windows or IBM Presentation Manager. Pay particular attention to whether the program will use graphics (a GUI interface is a necessity), whether it will be mass marketed (or is intended for a very small vertical market), and whether the users with whom you are working will be the same users that use the program later.

3.After the program’s basic functionality and operating environment have been selected, the user interface then is developed. The user interface is the most important part of the program. In a GUI program, follow standards that already have been established, including Microsoft’s guidelines and IBM’s book Systems Application Architecture Common User Access Advanced Interface Design Guide. Resist the urge (and pressure from others) to do your own thing when you are writing GUI Windows applications. A prime example is a program for Microsoft Windows that, although it’s a good application, has a nonstandard user interface that makes using it nearly impossible if you are an experienced Windows user.

162

4.After the basics of the user interface are developed (at this point there probably won’t be much functionality), potential users should review the interface and suggest additional functionality.

5.Create and implement the standard parts of the user interface, such as the capability to open, close, and save files. Create the help access. Create the look and feel of the application’s screen. You probably won’t ever face a “look and feel” lawsuit, and the standards make it easier for users to become familiar with your program. The fewer unique things the user must learn, the less support you have to provide.

6.Add each of the functionalities, one at a time, that the program requires. Each can have its own source file and should be fully self-contained. Don’t use too many shared supporting functions: Wanting to change a supporting function is common, but problems occur when some calls to these functions then fail.

Utility functions—the building blocks of your programs—should be as simple as possible.

Suppose that you have a large program, which therefore is divided into several source files. How do you put the pieces of the program together and create a single program that runs? The process of creating a large, multisource file program is shown in Figure 6.1. It shows generically what you must do (at a minimum) to create a multisource file program. You first compile all of your source files and then link them.

Figure 6.1. A multisource file program.

163

Part I • Honing Your C Skills

Compiling Multifile Programs

Compiling a multifile program isn’t much more difficult than compiling a single-file program. Many compilers can perform the compile and link using a single command, usually either CC or CL; other variations exist, however. You must tell the compiler that it should not link the program when it does the compiling. You tell it (with the Microsoft compilers) by using the /c option, which simply specifies that you want only a compile.

A couple of things are necessary in creating a functioning multisource file program:

•Be sure that you have properly defined each variable that will be shared between different parts of the program, using the extern keyword.

•Be sure that all functions have a single sharable prototype the compiler can use. Never create more than one copy of the prototypes: Make a single copy and place it in a shared header file (this subject is discussed in this section).

Because function parameters and shared variables (to a lesser extent) are the primary methods of passing information among different functions in the program, by defining them properly you increase the likelihood that the program will run properly.

Because you don’t yet have an automated system to control which of the source files is compiled (don’t try to remember “I changed this one, but not that one”), you must compile each source file. For projects that have only a few source files, compiling each one isn’t as bad as it seems; if you have several hundred source files, however, compiling all of them every time a change is made is a little excessive. Later, the “Using MAKE Files” section discusses automated project systems and how to make your program creation more efficient.

Linking Multifile Programs

When you are linking a program, the linker requires a minimum (other than options) of the name of the compiler output .OBJ file. This name then is used for the executable program’s name (which has an EXE extension under DOS on the PC). If more than one object file is specified, the first file’s name is used if no executable filename is specified.

164

The linker, whose command line can be lengthy, accepts a multiline command line. You type the first line and end it with a plus sign (+) and a return. The linker then prompts for the next part of the command line. This process of continuing the command line can continue for as long as necessary.

The following short code fragment shows a typical larger multisource file program’s link command. (You shouldn’t have multiple lines with comments in a real command).

The link command has a number of options (all of which probably will be different for other linkers). These options tell the linker to include line number information for the debugger (/linenumbers), align objects on 16-byte boundaries (/al:16), not use the default libraries (/nod) that the compiler inserts in the OBJ files, and create a load map used for debugging (/map).

After the options are the input OBJ files. You can generally omit the OBJ extension. You can specify as many OBJ files, separated by blanks, as you want. If several OBJ files are needed, you may have to use the multiline command format.

Then the name of the output file is specified. This filename receives the EXE extension if no extension is specified. If no output filename is provided, the executable filename is derived from the name of the first OBJ file.

The next parameter is the name of the linker map file. This file (see Chapter 16, “Debugging and Efficiency,” for an example) is useful for debugging your program and for certain performance considerations. If you don’t specify a filename and the /map option is specified, the map filename is derived from the executable file’s name.

The final parameters are the libraries. This parameter (like the input OBJ files) can have more than one name, separated by blanks. If you have specified the /nod option, you must specify all the necessary libraries; otherwise, it is necessary to specify only the libraries that are special to this program. It is not an error to specify a library that is not needed, and the linker does not load extra code if an unneeded library is specified.

165