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)
   {
    numberOfViews++;
   }
};

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