C PROGRAMMING

SD '95 East, ANSI C++, Framework Wars

The specification states that "...the scope of the name(s) declared extends to the end of the for-statement." This is quite different from how the C++ language works now.

A lot of existing code will be broken by this change. In fact, the committee's example does not even compile with contemporary compilers because the declaration, under current rules, is in the same scope as the for statement. Example 1(b) shows the effective code and scope if you substitute an independent declaration and a while loop.

Clearly, you could not declare another i integer after the while loop because the first i integer is still in scope. And here's where the ANSI specification springs a leak. Earlier on the same page, the specification uses just such an example to demonstrate the operation of the for statement. C'mon guys, which way is it?

Example 1(c) shows a common idiom that uses the current rules to advantage. Change the rule, and a lot of similar code no longer compiles. If there happens to be another int i in an outer scope in Example 1(c), the program compiles okay under the new rule, but it stops working properly.

Bjarne Stroustrup prefers the new rule and wishes he had specified it that way originally. If he had, this issue would not exist today. He did not, however, and now he has successfully campaigned to have the committee correct what he perceives to be his earlier mistake. Over the years Bjarne's influence has led the committee down many paths, mostly good. His championing of STL and the template changes that STL needs, for example, was a major step forward for the language. But this change is, in my opinion, a mistake. That's because: 1. I really like the earlier usage; and 2. I don't think the change's benefits outweigh its consequences.

Bjarne disagrees. The decision to effect this change was not made lightly. According to him, the decision was debated and postponed for years because of concerns for existing code, teaching materials, compilers, and so on. His winning argument to the committee in favor of the change was:

You will have programmers complaining whatever you decide, but personally I will feel better defending the cleaner and--based on experience--more intuitive rule than apologizing for the old rule and explaining what code the change would break.

So it is what it is, and for a time we will be in transition until all compilers comply and all old programs are converted. During the interim I would encourage compiler vendors to include a compile-time option, perhaps a pragma, that retreats to the older rule. Better yet, a warning that alerts programmers about the potential change to what was an overriding scope. Programmers should code to the new rule, but if an older program fails to work properly with a new compiler, this new behavior might be the problem.

enum as a Type

I don't know if this next change is intentional or merely the result of one compiler vendor's interpretation of an ambiguous specification. It turned up when I ported the code in Example 2(a) from Visual C++ 2.0 to the beta Visual C++ 4.0. Example 2(b) is the message the compiler returned to me.

According to Microsoft's interpretation of the ANSI specification, you have to overload the arithmetic operators for enum types. The relational operators still work the way they always did. Example 2(c) shows the overloaded operator function for the postfix ++ operator. After that, you need the prefix ++ operator, the two decrement operators, the binary addition and subtraction operators, and the op-equal addition and subtraction operators. Finally, all those operators must be overloaded for any other enum types you define.

I pored through the ANSI draft specification, but I could not determine from the document with any degree of certainty whether Microsoft's so-called new behavior is proper or improper. Unless I missed something, which is possible given the complexity of the document, this behavior is totally implementation dependent, subject to the compiler builder's interpretation of the specification. If that assumption is correct, the portability of the language has been seriously compromised. If incorrect, and Microsoft is right, this change to the way that enum variables work might make for a more type-safe language, but it will certainly break a lot of existing code. If Microsoft is wrong, the committee needs to tighten up the specification.

MFC versus OWL

In a recent column, I expressed my opinion that the Microsoft Foundation Class (MFC) library is the best of the Windows program-framework class libraries. That opinion generated more heated response than anything I've said since I suggested that OS/2's installation procedure makes huge vacuum-cleaner noises. I seem to know the way to the heart of a programming religious issue. Mostly I heard from programmers who prefer Borland's Object Windows Library (OWL) over MFC. OWL is, they say, more object oriented than MFC. Maybe. Is that necessarily true and, if so, is it better? It's a matter of opinion. Does OWL encapsulate more of the Windows API than MFC? Perhaps. It seems to. OWL also seems to hide more of the API, making it more difficult to get at things either not supported or encapsulated in a way that the programmer wishes to override. These discussions, mostly online, went on for a time, devoting only the first few messages to the relative merits of either class library. After that, they concentrated on what constitutes a de facto standard, whether Microsoft is force-feeding us something, and whether the trade press (me) is being taken in by hype. More message bandwidth was given to Microsoft bashing and defending than to the technical issues, which might point to the true heart of the religious wars.

The two sides squared off and fired their volleys back and forth. It was a friendly exchange, and I won't go further into the details of the battle. Mostly I stood back to see which way it went.

It soon became evident that if you start with MFC, you like MFC; if you start with OWL, you like OWL. Most of the commentators had not spent a lot of time with both products, which is to be expected. You do not, in the course of making a living, dedicate substantial time to two competing, mutually exclusive tools. It is natural, then, to prefer the one you use. The respondents seemed to believe that C programmers who already knew the Windows C API preferred MFC, while C++ programmers with little or no exposure to Windows programming preferred OWL. That was not my experience. I am in the latter group and prefer MFC. But, having developed DOS application-framework function and class libraries (D-Flat and D-Flat++), my experience and bias might not be typical.

A recurring theme was that influential columnists are irresponsible when they state their opinions so unequivocally. That position is taken only by those who disagree with the opinions, of course. First, you overestimate my influence. I could write until my mug was cerulean about my favorite programmer's editor, and not one of you would switch. Second, what difference does it make if a few people decide to use what I use. If it works for me, it should work for them. Are programmers somehow diminished when their choice is the different (or same) drummer? I don't think so.

I expected objections from the vendors of the competing class libraries, but they didn't make a peep. Maybe they dismiss my opinions as the wild ranting of an uncontrollable and out-of-control programmer. Maybe they're right. On the other hand, maybe they secretly agree with me. I doubt it.

Those of you who cared enough to object got one thing right. My experience with OWL is probably not current enough to simply say that MFC is better. I like MFC better, so I use it, which accounts for my more current knowledge of its capabilities. I did not intend to give the impression that other class libraries are not worth a look.

Example 1: (a) New C++ for statement; (b) the effective code and scope if you substitute an independent declaration and a while loop; (c) common idiom that uses the current rules to advantage.

(a)
int i = 42;
int a[10];
for (int i = 0; i < 10; i++)
    a[i] = 1;
int j = i;      // j = 42;

(b)
int i = 0;
while (i < 10) {
    a[i] = i;
    i++;
}

(c)
for (int i = 0; i < maxentries; i++)  {
    // ...
    if ( ... )  // some loop-terminating condition
        break;
}
if (i < maxentries)
    // the loop was broken before reaching the end

Example 2: (a) Code being ported from Visual C++ 2.0 to the beta Visual C++ 4.0; (b) message returned from the compiler; (c) the overloaded operator function for the postfix ++ operator.

(a)
enum Color { red, green, blue };
int main()
{
    Color clr = red;
    clr++;
    return 0;
}

(b)
error C2676: binary '++' : 'enum 
Color' does not define this 
operator or a conversion to a 
type acceptable to the predefined 
operator (new behavior; please see help)

(c)
Color operator++(Color& c, int)
{
    Color temp = c;
    int cc = c;
    c = static_cast<Color>(++cc);
    return temp;
}