January 92 - The Soup Kitchen - Extending C++ with C++
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
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()
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()
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);