The Soup Kitchen - Extending C++ with C++

Eric M. Berdahl

This month I'll look at C++ from a slightly different perspective. One of my central themes has been object code compatibility with Pascal and MacApp. But this will not be an issue today. Instead, I'll be looking at tools intended to make the C++ programmer's life easier by extending the language with "pure" C++ classes.

THE MEANING OF "EXTENDABLE"

Most languages are judged, at least initially, by the support they provide for certain "key" issues. String manipulation is a typical example of such an issue.

Support for strings in C and Pascal marks two extremes of a spectrum. Pascal provides rather intuitive syntax for dealing with strings, while C provides for support via a powerful but non-intuitive library of functions. The advantage of standard C is the programmer's ability to easily create superior string handling functions at the cost of readability. The advantage of standard Pascal is the programmer's ability to create very readable code at the expense of flexibility.

C++ provides something between these C and Pascal. C++ doesn't have built-in support for strings, but the class structure and messaging protocol allows you to design string classes that are intuitive and easy to change. When this is done, you can use strings as if C++ has predefined definitions for what strings are and how to manipulate them. Furthermore, C++ lets you create small classes whose sole purpose is to aid in housekeeping chores or other code-level cleanup that is sometimes required when programming complex systems like the Macintosh.

HOUSEKEEPING À LA C++

General techniques One of the more tedious tasks facing Macintosh programmers is the necessity to save different states at various points in one's code. MacApp does nothing but add to the complexity of the problem. Lock state of handles, pen states, focused views, and permanent allocation flags are simple examples of things MacApp programmers need to keep track of and keep in sync with code.

The classic approach to this problem is to write code resembling the following:

{
    StateRecord aState;
    GetCurrentState(aState);
    //  Insert code here that screws around
    //  with the element we want to save
    SetCurrentState(aState);
}

This code is straightforward and works fine. However, it will run into problems when you need to contend with MacApp failure handling. In this situation, you need to provide failure handling code to restore the state appropriately, as follows:

{
    StateRecord         aState;
    FailInfo            fi;
    GetCurrentState(aState);
    if (fi.Try())
    {
        //  Insert code here that screws around
        //  with the element we want to save
        SetCurrentState(aState);
        fi.Success();
    }
    else
    {
        SetCurrentState(aState);
        fi.ReSignal();
    }
}

This code is functional and perfectly acceptable, though rather wordy. It uses a simple concept-it preserves the state across this section of code. This bit of housekeeping is a perfect candidate for an object.

The technique I describe here applies to all forms of housekeeping. But for sake of brevity, I'll restrict my explication to one application-locking a handle.

CHandleLocker
class CHandleLocker
{
private:
    Handle      fHandle;
    Boolean     fWasLocked;
    FailInfo    fFailInfo;
protected:
    pascal void HandleFailure(OSErr err, long message);
    virtual pascal RestoreLockState();
public:
    CHandleLocker(Handle theHandle);
    virtual ~CHandleLocker();
};

CHandleLocker is a simple class that assures a handle remains locked within a particular scope and that it reverts to its previous state outside that scope. Using CHandleLocker, you can write code that utilizes handle locking in the following manner:

{
    CHandleLocker   lockSomeHandle(someHandle);
    //  Insert code that relies on someHandle being locked
}

Magically, when this code block executes, someHandle will be locked. The intervening code will execute, and someHandle will be returned to the state it was in (either locked or unlocked) when the block began. As an added bonus, if a MacApp failure is raised somewhere in the intervening code, someHandle will still be left in its original state. Amazingly, CHandleLocker adds safe handle locking to C++, and gives it a syntax that is relatively simple and unobtrusive.

Under the hood of CHandleLocker

To accomplish this little bit of heaven, CHandleLocker relies on the constructor and destructor mechanisms of C++ classes. The constructor and destructor are the core of the class. The constructor is called automatically when an instance is created, as in the declaration of lockSomeHandle in the example above. The destructor is called when an instance is destroyed, as in the closing curly brace in the same example.

CHandleLocker::CHandleLocker(Handle theHandle)
{
    fHandle = theHandle;
    fWasLocked = IsHandleLocked(fHandle);
    if (!fWasLocked)
        HLock(fHandle);
    CatchFailures(fFailInfo, CHandleLocker::HandleFailure, this);
}

CHandleLocker::~CHandleLocker()
{
    Success(fFailInfo);
    this->RestoreLockState();
}

The constructor simply saves the handle and its original lock state in instance variables. If the object is originally unlocked, it locks it. Finally, a MacApp failure handler is installed. In the destructor, the failure handler is removed and the lock state is restored. The remaining parts of the class are the method to restore the lock state and the failure handler:

void CHandleLocker::RestoreLockState()
{
    if (!fWasLocked)
        HUnlock(fWasLocked);
}

pascal void CHandleLocker::HandleFailure(OSErr err, long message)
{
    this->RestoreLockState();
}

RestoreLockState is straightforward. It simply refers to the fWasLocked boolean instance variable and unlocks the handle if it was originally unlocked. But the failure handler is a bit more involved and will take a short explanation.

CHandleLocker::HandleFailure is mediated using the Pascal-style failure handling routines, CatchFailures and Success. Therefore, the failure handling routine does not need to resignal the failure since returning from the routine automatically invokes the next failure handler on the stack.

Also, the method is declared with the keyword pascal, indicating that we want the return values and arguments passed Pascal-style. This is important once you recognize that methods with Pascal-style arguments will have the metavariable this passed as the last "argument" of the routine, the same position the Pascal static link variables occupy (see the September installment of The Soup Kitchen for a discussion of nested procedures and static links). Notice that this is passed as the static link variable in the CatchFailures argument list above.

That's all there is to this simple little utility class. I challenge the reader to write utility objects to handle other housekeeping chores. To get started, look at the PenState of QuickDraw, and the focus information in the MacApp view architecture. It should be fairly simple to use CHandleLocker as a template to build a useful library of magic little objects.

STRINGS

Admittedly, utility classes are simple examples and do not come close to making the case for language extensibility. However, having opened the door and provided some decent groundwork, let's take a look at CStr255, a very nice piece of work from the MacApp Team at Apple.

Any Macintosh programmer is familiar with the basic Pascal string. The Pascal string differs from the C string in the following ways:

• Pascal strings are limited to 255 characters; C strings are basically unlimited in length.
• Pascal strings contain the length of the string in their first byte; C strings are terminated with a null byte (hex 00).
• Pascal strings are supported with Pascal language syntax; C strings are supported by convention and a standard C library.

Pascal programmers are fortunate to be able to use standard Macintosh strings, Str255, with little or no effort. Since these strings are nothing more than real Pascal strings, the compiler and run time environment take care of the details. The C++ programmer has the ability to use Pascal-like syntax to define and manipulate Pascal strings, but must be constantly aware of the difference and must maintain discipline to convert to the appropriate format as necessary.

Unlike the example of maintaining the lock state of a handle, writing a fully capable language-extending class like CStr255 is beyond the skill of all but master C++ architects. CStr255 provides an excellent example of what C++ can do, but it should not be imitated by the novice. This warning is sorely lacking in all C++ books I've encountered and is the primary cause of problems with novice and intermediate level C++ programmers. To quote Barnum and Bailey, "Kids, don't try this at home."

In its final form, CStr255 allows you to write code that looks like this:

{
    CStr255 aString;
    aString = "A string";
    aString = aString + "another string";
    if (aString == anotherString)
        gApplication->Beep(3);
    theLength = aString.Length();
    theFifthCharacter = aString[5];
    DrawString(aString);
    DrawString("A string constant");
    printf("This line prints C strings %s", (char*)aString);
}

In short, you can write code that looks like Pascal but that integrates well with your C++ code.

Constructor magic

The first rabbit I'll pull out of CStr255 involves its constructors. The designers of CStr255 provide a constructor that takes a single char* as an argument: CStr255::CStr255(char*).

Since all standard C strings and string constants in C++ are of type char*, this means you can assign C strings and string constants directly to any variable of type CStr255. Furthermore, any routine that takes a CStr255 as an argument, like DrawString, can be passed a C string or string constant with no difficulty.

Similarly, CStr255 provides for constructors from other Macintosh string types (CStr63 for example), other C types (like unsigned char*), and even a constructor from a longint that is used to convert ResType and OSType variables to their string equivalents. As with all the CStr255 code I'll quote from here, these constructors are found in the file PascalString.h in the MacApp 3.0b3 release.

Operator magic

Constructors are handy and useful, but without the operators +, =, ==, and others, CStr255 would just be a neat utility class. Instead, with these operators, you have access to a truly powerful class that adds Pascal strings to the C++ language with a very simple and intuitive syntax. Since it's not reasonable to reproduce the CStr255 code here, I'll leave you with a taste of the features available for string handling and short examples of their utility.

Constructors

CStr255();                            //  CStr255 aStr
CStr255(char*);                       //  aStr = "A string"
CStr255(const CStr255&);          // aStr = anotherStr255
CStr255(const CStr63&);           //  aStr = aStr63
CStr255(long);                        //  aStr = 'PICT'

Operators

char& operator[](short pos);      //  aStr[4] = 'P'
CStr255 operator+(CStr255&);      //  aStr = bStr + cStr
CStr255 operator=(CStr255&);      //  aStr = bStr
Boolean operator==(CStr255&);     //  if (aStr = bStr)
Boolean operator==(const char*);      //  if (aStr == "A string")
Boolean operator>(const char*);    //  if (aStr > "ABC")

Handy functions

char& Length();                   //  aStr.Length() = 7
Boolean IsEmpty();                    //  if (aStr.IsEmpty())

Conversions

operator char*();                     //  printf("%s", aStr);
operator long();                      //  GetResource(long(aStr), kID);