C/C++ Control Structure Limitations?

Question

I have heard of a limitation in VC++ (not sure which version) on the number of nested if statements (somewhere in the ballpark of 300). The code was of the form:

if (a) ...
else if (b) ...
else if (c) ...
...

I was surprised to find out there is a limit to this sort of thing, and that the limit is so small. I'm not looking for comments about coding practice and why to avoid this sort of thing altogether.

Here's a list of things that I'd imagine could have some limitation:

• Number of functions in a scope (global, class, or namespace).
• Number of expressions in a single statement (e.g., compound conditionals).
• Number of cases in a switch.
• Number of parameters to a function.
• Number of classes in a single hierarchy (either inheritance or containment).

What other control structures/language features have limits such as this? Do the language standards say anything about these limits (perhaps minimum requirements for an implementation)? Has anyone run into a particular language limitation like this with a particular compiler/implementation?

EDIT: Please note that the above form of if statements is indeed "nested." It is equivalent to:

if (a) { //...
}
else {
    if (b) { //...
    }
    else {
        if (c) { //...
        }
        else { //...
        }
    }
}

Answer 1

Visual C++ Compiler Limits

The C++ standard recommends limits for various language constructs. The following is a list of constructs where the Visual C++ compiler does not implement the recommended limits. The first number is the recommended limit and the second number is the limit implemented by Visual C++:

• Nesting levels of compound statements, iteration control structures, and selection control structures [256] (256).

• Parameters in one macro definition [256] (127).

• Arguments in one macro invocation [256] (127).

• Characters in a character string literal or wide string literal (after concatenation) [65536] (65535).

• Levels of nested class, structure, or union definitions in a single struct-declaration-list [256] (16).

• Member initializers in a constructor definition [6144] (approximately 600, memory dependent, can increase with the /Zm compiler option).

• Scope qualifications of one identifier [256] (127).

• Nested external specifications [1024] (10).

• Template arguments in a template declaration [1024] (64).

Answer 2

Do the language standards say anything about these limits (perhaps minimum requirements for an implementation)?

No, the standard sets no minimum limits on this. But it is good practice for an implementation to set and document a hard limit on such things, rather than fail in some unknown way when the limit is exceeded.

Edit: The standard recommends some minimum limits In Annex B - there are really too many to post here and they are in any case advisory:

The limits may constrain quantities that include those described below or others. The bracketed number following each quantity is recommended as the minimum for that quantity. However, these quantities are only guidelines and do not determine compliance.

Answer 3

C specifies that implementations must be able to translate a program that contains an instance of each of a number of limits. The first limit is that of 127 nesting levels of blocks. (5.2.4.1 of ISO/IEC 9899:1999)

C doesn't say that any valid program that contains no more than 127 nesting levels must be translated; it could be unreasonably large in other ways. The rationale was to set some level of expectation that portable programs can have, while allowing latitude not to exclude small implementations and implementations targetting small systems.

In short, if you want more than 127 nesting levels it probably means that you should consult your implementation's documentation to see if it guarantees to support a larger number.

Answer 4

Just to put the whole scoping thing to bed, the following is legal C++ code:

int main() {
    if ( int x = 1 ) {
    }
    else if ( int x = 2 ) {
    }
}

which it would not be if both the if and the else if were at the same scope. I think there have been a lot of misunderstandings, perhaps engendered by my comment:

The compiler cares a great deal about scope. 

which is of course true, but maybe not helpful in this situation.