August 91 - How to Cope with Nesting Instinct (in C++)
How to Cope with Nesting Instinct (in C++)
Eric M. Berdahl
MacApp 3 will add large amounts of spice to programming recipes. There are new
classes, new twists on old classes, and new hoops to jump through.
However, the more interesting items are from the primary language of
implementation changing from Pascal to C++. In fact, I propose that MacApp 3's best
features are its solutions to the so-called "Nested Procedure" problem.
As a software author, I spend a fair amount of time listening to a short description of
some problem a user is having and a longer description of what the user wants to do to
solve it. Sound familiar? Sometimes the user is right on the money as to the nature of
the "right" solution, but more often it is their description of the problem that is most
revealing. I view the Nested Procedure problem in that light. I don't necessarily want
nested procedural constructs, but I do have a problem to solve.
One solution is to implement language support for grouping sets of code in some logical
order. The Pascal language provides this. However, it's not the only solution, nor is it
the only solution for the MacApp programmer-at least not for the ones who use C++.
This article will examine the nested procedure problem, look for solutions, and
discuss what this has to do with MacApp. First, I'll describe the problem in more
detail. This may seem obvious and repetitive, but the goal is to come up with something
that does what nested procedures in Pascal do. In addition, the solution should be link
compatible with Object Pascal.
SCOPES?
Let's examine some textbook descriptions of Pascal. Pascal lore provides many ideas
from which one may leverage; one of the most useful is the concept of scopes.
Simply put, a scope is the range over which a coding entity-variable, constant, or
routine-is meaningful. Languages like assembly generally recognize only one scope,
global. That is, once you get down to the assembly level, everything is visible to
everyone all the time.
Moving up one step, there is C. C recognizes two basic scopes, global and local. That is,
something is either scopeless-global-or it exists within a specific routine.
Languages like Pascal maintain a highly ordered, scoped hierarchy. Pascal's
description of scoping is so good, in fact, that to many people, Pascal's implementation
is scoping.
ABRACADABRA!
You might ask, at this point, "But when I write Pascal code, I don't really have to
worry about scopes, do I?
Probably not, but you do have to be careful. For example, many of you may remember
something like the code in Listing 1 from a Computer Science 101 test. The exam
would quiz you on the output of the program; to answer correctly, you would have to
recognize that there are overlapping scopes and resolve them appropriately.
In a more practical world, you might see something like Example 2. Example 2 calls a
procedure, DoSomethingToIntegers, telling it what action it wants performed, namely
DoToInteger. Furthermore, DoToInteger has some magic knowledge of the local
variables, oneInt and twoInt. Pascal accomplishes this by giving the nested procedure,
DoToInteger, an additional parameter referred to as a "static link" variable. The static
link is a pointer to the stack frame of the enclosing routine.
Thus, when a Pascal nested procedure is called, a pointer to the routine's stack frame
is passed as a hidden argument. Also, when a routine is passed as a procedure
parameter to a Pascal routine, as is done with DoToInteger, a pointer to the routine's
stack frame is passed as an additional parameter. In the example,
DoSomethingToIntegers actually takes two parameters, the routine to execute,
DoToInteger, and a value to pass as the static link parameter to the indicated routine.
OH, I C
A person emulating this concept in a C-based language could write something like
Example 3. This construct directly translates Pascal's mechanism into C's. It also
looks ugly. For some reason, Pascal's elegance has been lost. Pascal deals elegantly
with the static link problem; as a programmer, I don't need to deal with it. I just write
my code and let Pascal take care of the overhead.
In Example 3, you could just pass DoSomethingToIntegers a pointer to oneInt, and have
CBasedDoToInteger know that staticLink is a pointer to a short, namely oneInt. But that
means it won't know about twoInt! Alternatively, you could define a structure that
holds oneInt and twoInt, and pass a pointer to the structure for the static link, but
that's unattractive. Clearly, it's better to refine and generalize the solution.
DOING IT right IN C++
Simple emulation doesn't seem to solve the nested procedure problem. Nonetheless,
Pascal has provided a good starting point, and later we'll return to it. For the moment,
however, let's look at another avenue-object technology. Regardless of the language to
which it is bound, object concepts provide the programmer with another layer of
scoping.
The key to an object-based approach is to recognize that, implicitly, a method is
scoped to exist within an instance of an object. I tend to avoid hard-core C++
documentation (except during psychotically masochistic episodes), but in most C++
texts, the descriptions of objects as scopes-and the implications of this for visualizing
program constructs-are very good.
For the problem above, a class could be defined, like CDoToInteger in Example 4, to
handle the hard work. CDoToInteger looks much closer to what's desired than
CBasedDoToInteger in Example 3.
"But where did the mystical staticLink parameter go?" the intrepid reader asks. It's
hidden by the magic of object programming, just as it was hidden by the magic of
Pascal in the Pascal example. In the object programming case, the scope is determined
by the implicit variable this (SELF for you Pascal fans, Current for you Eiffel fans).
Look again at CPlusFoo in Example 4 to see how the CDoToInteger class might be used.
I've indicated a routine to invoke-CPlusDoToInteger in the scope of CDoToInteger-and
indicated a context in which to execute the routine, aScope. That's it, right?
Not quite. I still have to find some way for aScope to know about oneInt and twoInt
within CPlusFoo. One solution might be to set the individual instance variables of
aScope to hold the same values as the local variables of CPlusFoo, but that's not what I
really want. I want the oneInt and twoInt variables of CDoToInteger to be pointers to
oneInt and twoInt in CPlusFoo, but I also need to ensure that those pointers are never
nil.
This is the second and last reason that to reasonably use reference variables in C++
MacApp code. (The first involved parameter passing, and was discussed last issue.) So,
the CDoToInteger class is finished in Example 5. The careful reader will notice that the
declaration of CPlusDoToInteger changed subtly in this last revision. It now carries a
Pascal calling sequence, so that it's compatible with Pascal. The difference here is the
order in which parameters on the stack are evaluated. The declaration above indicates
that the magic this parameter is to be the last parameter pushed on the stack, just like
the Pascal magic static link is pushed on last. Ta da.
A PRACTICAL EXAMPLE
So, how might one use such information in a real MacApp application? Consider a
common situation, that of iterating over items in a TList:
class CCountSubViews {
private:
long& numberOfViews;
public:
CCountSubViews(long& aNumberOfViews) :
numberOfViews(aNumberOfViews) { }
pascal void CountSubViews(TView* aView)
pascal void TMyView::CountSubViews()
long numberOfSubViews;
CCountSubViews aCounter(numberOfSubViews);
fSubViews->Each(CCountSubViews::CountSubViews,
&aCounter);
}
You can come up with more relevant examples, I'm sure, but I chose this particular
example for a reason. Each is a method that allows a routine to iterate over the items
in a TList. This can be used with the magic of Pascal and nested procedures; however,
MacApp 3 provides C++ users with another way to iterate.
ITERATORS
Often the best way to solve a problem is to avoid it. It would be nice to avoid writing
helper classes, and just bring iteration into the mainstream of code. After all, anyone
is used to iterating over integers and other built-in types with simple for loops:
// Find the sum of all integers on the interval [0..4]
short a;
a = 0;
for (short i = 0; i < 5; i = i + 1)
a = a + i;
}
MacApp 3 provides a nice mechanism for doing this-iterators. A library of iterator
objects (sorry, C++ users only) is available for doing a variety of iterative actions.
The following is an example of CObjectIterator, the class for iterating over objects in a
TList:
CObjectIterator iter(aTList);
for (TObject* anOb = iter.FirstObject(); iter.More();
anOb = iter.NextObject())
// do something with anOb here
}
Within the body of the loop, you can manipulate anOb just as you would any local
variable. The reason for this is that anOb is a full-fledged local variable. So, if you
happen to know that aTList only contains instances of TFoo, you can easily (and
legally) cast anOb to TFoo*.
Iterator classes are provided for most of the basic iterations. For example, the
CSubViewIterator class, iterates over each subview of a given TView. You might use it
in the following fashion:
CSubViewIterator iter(aTView);
for (TView* aView = iter.FirstSubView(); iter.More(); aView =
iter.NextSubView())
// do something with aView here
}
NEXT TIME
Next issue, I'll look at the wild and woolly world of MacApp 3. I'll show what new
functionality it provides, what you might want to tap into right away, and what you'll
want to study first. Keep those cards and letters coming!
Tech Note #265
For more information on Pascal PROCEDURE parameters, I refer the inquisitive
reader to Tech Note #265: Pascal to C - PROCEDURE parameters. n