Review

We started this chapter by creating a new xstring class based on the standard library string class, so that we could add some new functionality to the home inventory program. Before we started to examine the functions in this class, the first new construct we encountered was the include guard, which is a means of preventing the C++ compiler from seeing the same class definition more than one time for a given source code file. Implementing the include guard required us to look at some very old parts of C++ dating back to the early days of C: the preprocessor and its preprocessor symbols. The preprocessor was originally a separate program that was executed before the compiler itself, but nowadays it is usually physically part of the compiler. Most of its features are no longer needed in C++, but we still need it to create an include guard as well as to handle included header files — its most common use these days.

After dealing with that new construct, we went over the implementation of the functions in the new xstring class, starting with the constructors, which allow us to create and copy objects of this new type, including making them interoperate with objects of the standard library string class. Then we continued by examining the first regular member function of this class: find_nocase. This function looks for a sequence of characters within a particular xstring without worrying about whether the case of the characters in the “target” xstring matches the case of the specified sequence of characters. We needed this ability to implement the functions that allow the user to find items whose descriptions or other fields contain a specified sequence of characters. During the discussion of this function, we ran across a (non-standard) C library function called strnicmp, which compares two C strings without considering the case of the characters in them. This is an important feature to provide because the user may not remember the case of the word for which he or she is looking.

The second and final regular member function in the xstring class is less_nocase. It is exactly like the normal operator < function in the string class that we created earlier in this book, except that it uses the strnicmp function to do the comparison so that upper- and lower-case characters will be compared without regard to considering their case. This was necessary in the implementation of the sorting routine in SortInventoryByName.

After finishing the discussion of the less_nocase function, we looked at an example program that illustrates the use of one of the newly added “find” functions, FindItemByDescription, which, as its name suggests, searches for an item whose description field contains a particular sequence of characters. After a brief description of this new example program, we started to tackle the latest version of the HomeInventory class, hmin6.h. Besides adding the new member functions needed to support searching for items by name or description, I took this opportunity to change the argument-passing conventions of all of the member functions that previously used value arguments of user-defined types to use const references instead. This is usually the best way to pass arguments of user-defined types because it avoids the necessity of making a copy of the argument. Arguments of native types, on the other hand, typically are best passed by value, as copying them is not very expensive.

Next, we discussed FindItemByDescription, which is very similar to the previously defined FindItemByName, except that it uses the new find_nocase function to search for an item that matches the user's partial description.

At this point, we were ready to look at the next version of the HomeItem interface, hmit6.h, which differs from the previous version of this interface in a few minor ways. First, I changed all the arguments of user-defined types to use const references rather than pass-by-value, just as I did with the HomeInventory class. I also added two new functions, GetDescription and IsNull. Neither of these functions is at all complicated, so we passed over them quickly.

At that point, I fondly believed that I had all the pieces to complete the home inventory project. Therefore, I wrote what I thought would be the final version of the program and submitted it to my beta tester, Susan, for her approval. I was quite surprised to discover that we still had a long way to go. After she had taken a look at the program, both in execution and in source code, we embarked on a voyage of discovery to find and fix errors and inconveniences, and to find ways to improve the functioning of the program. The next 10 pages or so of the chapter consisted of a repeated cycle of the following steps:

Most of the changes I made fell into three main categories: fixing errors (including improved error handling), cosmetic changes (such as position of items on the screen), and improvements to the functioning of the program (such as allowing the user to select items by category). There were also a few changes that I didn't make because they would have required effort out of proportion to their importance in the functioning of the program. Instead, I left them as exercises, which you will see at the end of the next chapter, after we have gone over the code of the final version of the program.