scope of a variable declared in a for loop

I didn't quite understand

Quote:

---

it is NEVER a good idea to jam a variable declaration into a for statement

---

There are two meanings one can derive from this statement

Code:

---

for (int i = 0; i < 1000; i++)
{
    int a = b[i];
    ...
}

---

Is "i" or "a" the jammed variable declaration? There is no reason why "i" is a bad idea since it is only created once and only exists for the duration of the loop. "a" is a bad idea because it calls the int constructor every time. Since the topic of conversation is the loop control variable and declarations with the loop body, why bring this up?

Anyway, in my younger days, the term jamming meant something else: it was a form of optimization i.e.

Code:

---

// unoptimized loop
for (i = 0; i < 1000; i++)
    a[i] = 0;
for (i = 0; i < 1000; i++)
    b[i] = 1;

// Jammed loop
for (i = 0; i < 1000; i++)
{
    a[i] = 0;
    b[i] = 1;
}

---

I think that the point of this matter is the code

for(int i=0; i<10; i++)
//blah

will only compile on VC++ because it doesn't conform to the ANSI standard. What people have to realise is that this standard was developed years ago and it was a god send. I am just surprised that Microsoft haven't tried to alter the standard to accomodate for this technique (or have they??). Although I think the VC++ does make sense, it is certainly not self explanatory. The ANSI standard ensures that code is self explanatory and portable. The first param (as I said earlier) is meant for initialisation under ANSI standards, not variable declaration AND initialisation, which are two different things. Since this technique is not standard practice, I think it is better to declare it right before the for loop and not during the statement, because it makes life easier for everybody - remember that is what the ANSI standard was designed to do. As ... pointed out earlier, the code compiles into the same executable independant of whether the variable was declared in the for statment or outside it, its just probably more readable being declared outside the loop because then nobody would be bothered about the scope of the variable in the first place.

Alan.

The ANSI standard is saying that declaring a variable in the control statement is functionally equivalent to declaring it inside the loop body. I find that quite reasonable. MS didn't implement that because it would have broken a lot of code that came before the standard and that was developed using older versions of VC++.

Given that we live in a real world and, in that world, MS is a major player, I think that we need to suborn our desire to conform to the standard to the the reality of what is. To that end, my personal approach is:

1) Try to use one of the standard algorithms, if that's feasible and appropriate (e.g. for_each, transform, accumulate). These tend to increase self-documentation (unless you're shoe-horning them into an inappropriate use).

2) Don't use the same variable (name) to control multiple loops in the same scope unless the loops are trivial iterations (but see 1 above) using a fundamental type (like int) in which case, declare it before the first loop.

3) Where there is only one loop, or where the loops are fundamentally different (and 1 above doesn't apply), declare a variable dedicated to that loop in the loop control statement.

Quote:

---

Originally posted by Anthony Mai
Paul:

When you follow up, make sure you read my message first.

Which part of the code I cited can not be compiled on UNIX?

---

The question is very simple "What are the current rules of the ANSI standard?" And yes, the code that is cited by the OP (which is what I'm talking about) does not compile using a UNIX compiler.[quote]It is when you declare a variable in the for statement that ambiguity of what scope that variable belongs to raises, and you have to modify to cope with different compilers

Quote:

---

. It is a trouble that you invite in the first place by declaring something like for(int i=0;;).

---

What's troubling about it? That's the way C++ programmers naturally write loops. The troubling part is when a certain compiler doesn't follow the rules. You're a 'C' programmer, where you're forced to declare the loop variable outside the function block, so you are used to writing things that way. Do you also declare your variables at the top of the function block?

Quote:

---

And finally it is never without a reason that big potato compilers sale much better than small potato ones. It's something developers voted using their money. [/B]

---

And that is not what counts. There are rules to the language. The ANSI comittee doesn't meet and decide on compiler issues because a lot of people buy VC++. This is a case where VC++ cannot boss ANSI around -- if anything, VC++ is scrambling to get their compiler *more* ANSI compliant. So your comment about "small potatoes" and "big potatoes" is totally irrelevant to the discussion of what the rules of ANSI C++ are. The question asked by the OP was an ANSI C++ question, the answer was given.

Regards,

Paul McKenzie

Well said Paul, You got full marks. Now i want to add something about Big vendors like Microsoft.

What about take a closer look at VC 6 and gnu. I run these programs on VC 6 Nt 4 sp 6a and Gnu 2.96 on Red Hat Linux 7.2.

Here is valid C++ Program but VC gives warning to it and gcc compile it

Code:

---

int main()
{
}

---

According to C++ Standard 3.6.1.5

Quote:

---

If control reaches the end of main without encountering a return statement, the effect is that of executing

return 0;

---

This is valid code according to C++ Standard 3.4.2.2

Code:

---

namespace NS {
        class T { };
        void f(T) { }
};

int main()
{
        NS::T param;
        f(param);
}

---

But VC refuse to compile it.

Here is one more example. Here is a valid program according to C++ standard and compile correctly but refuse to compile on VC 6

Code:

---

#include <vector>
#include <list>
#include <algorithm>
#include <iostream>
using namespace std;

int main()
{
        vector<int> vec;
        list<int> lst;

        vec.push_back(1);
        lst.push_back(2);
        lst.push_back(3);

        vec.insert(vec.begin(), lst.begin(), lst.end());
        copy(vec.begin(), vec.end(), ostream_iterator<int>(cout, "\n"));

        return 0;
}

---

Because insert member function of vector should be template function according to 23.2.4.3 section of C++ Standard but it is not template in VC 6.

Same is true in case of list 23.2.2.3, assign function of deque section 23.2.1.1.6 and insert of deque section 23.2.1.3

Also VC 6 didnt support exception specification, partial template specialization.

Now what about big Names?

Hello Zeeshan,

How about the opposite of your first example. This shouldn't compile whatsoever:

Code:

---

void main()
{
}

---

VC++ 6.0 compiles this, without error. The problem is that this code is invalid. Throw this code at another compiler, and you get the error that "main() must be defined as returning int", or something similar to that.

The C++ examples in MSDN are littered with this code. Also, a rule of thumb when buying C++ books is to look for the above. If the author uses it, get another book!

Of course, the fix is to do this:

Code:

---

int main()
{
}

---

You would think that VC++ would fix this, but so far, they haven't. (I haven't tried NET, but I bet it hasn't been fixed).

Regards,

Paul McKenzie

Yes paul you are right, i check this code on Win 2000 Server SP 2 with VC.Net and this code correctly compile there too.

Code:

---

void main()
{
}

---

Also VC.Net havnt fixed Koenig Lookup yet, this is still error in VC.Net although it is legal code.

Code:

---

namespace NS {
        class T { };
        void f(T) { }
};

int main()
{
        NS::T param;
        f(param);
}

---

In the same way this code is not legal in Standard C++

Code:

---

namespace NS {
        class T { };
        void f(T) { }
};

void f(NS::T) { }

int main()
{
        NS::T param;
        f(param);
}

---

But VC.Net compile it sucessfully. For further information take a look at Item 32 of Exceptional C++ by Herb Sutter. But VC.Net at least solve insert and assign problem of STL. Now this code compile sucessfully at VC.Net

Code:

---

#include <vector>
#include <list>
#include <algorithm>
#include <iostream>
using namespace std;

int main()
{
        vector<int> vec;
        list<int> lst;

        vec.push_back(1);
        lst.push_back(2);
        lst.push_back(3);

        vec.insert(vec.begin(), lst.begin(), lst.end());
        copy(vec.begin(), vec.end(), ostream_iterator<int>(cout, "\n"));

        return 0;
}

---

and this one also compile sucessfully on VC.Net

Code:

---

int main()
{
}

---

I havent check the VC.Net carefully according to ANSI standard, may be there are some more, but till now it hasnt support partial template specialization and exception specification.

Yeah but this IS microsoft we're talking about, whenever have they given a rats a**s about good programming techniques and robust coding? I just hope that, having identified these obvious flaws, people don't use them (because they are aware it is not good practice). I certainly have never declared a program statement

void main()
{
}

or

int main()
{
}

(even though the later complies with ANSI C++ standard. I feel lonely without that return 0; statement at the end :).

Alan.

Just as a side note -- some new programmers I've encountered have the impression that variables are actually allocated on the stack when they are encountered in the source code. In the VC6 compiler, this is not true -- all variables are allocated on the stack when the function is declared.

For example: if you have a function like this:

int foo()
{
for(int i = 0; i < 5; i++)
{
char buf[16];
// some code that does something
}

for(int x = 0; x < 5; x++)
{
char buf[16];
// some code that does something
}
}

In the above buf is actually using 32 bytes of stack space because it is declared twice, so the compiler must allocate space for both of them. The compiler allocates all stack space immediately following the function definition. (look at the assembly list file to see how this is done.)

If you are concerned about stack space, you should rewrite the function like this:

int foo()
{
char buf[16];
for(int i = 0; i < 5; i++)
{
// some code that does something
}

for(int x = 0; x < 5; x++)
{
// some code that does something
}
}

Part of the assembly output looks like this (my comments):

// Declare the function name
foo PROC NEAR ;
// save the current stack pointer
00000 55 push ebp
// Copy the stack pointer to a baseline pointer.
00001 8b ec mov ebp, esp
// Allocate space for all auto data objects declared within the function.
// This also includes space for the compiler's own temporary stack sace.
00003 83 ec 54 sub esp, 84 ; 00000054H

Quote:

---

Originally posted by stober
Just as a side note -- some new programmers I've encountered have the impression that variables are actually allocated on the stack when they are encountered in the source code.

---

Your "new programmers" should have stated that the ANSI C++ does not state where those variables should be stored. That would have been the proper answer. As long as the program performs the proper task (to ANSI specs), that is all that's required.

For example, everyone (or almost everyone) talks about the stack storing parameters when discussing C++ in general. The problem with this is that there are processors (and even compilers) that do not use a stack to store parameters. Computers based on RISC and Motorola processors have a boatload of registers, unlike the Intel processors. More than likely, these registers are used to store the parameters for these processors. On some other compilers, I believe there is a block of memory dedicated for arguments. If memory serves me correctly, the Watcom compiler uses registers if the parameter list is small. Same with the Borland compiler (a "fastcall" is what I believe Borland calls it).

Your code to "conserve stack space" may be the case for one version for a certain compiler, and maybe for a certain set of optimization switches for that compiler. If you used a different optimization, maybe the compiler would generate different code. Anyway, assembly listings become moot if you are using a different compiler or working in another OS.

Regards,

Paul McKenzie

Yes, you are correct about the parameters to the function. But the code and example I presented was about the auto data objects that are declared within the function. Also, my comments to not account for compiler optimizations when compiled for release mode. MSDN says VC6 may do "stack packing" for objects that are not within scope. By that, I assume that it will recognize the ineffiency in my example and allocate only 16 bytes for the buffer, not 32.

Some clarifications and some disputes.

When I say "it is NEVER a good idea to jam a variable declaration into a for statement", I mean the for statement that starts with a "for" and ends with a closing parenthesis. I call the code block that starts and ends with {} following the for statement the "for loop". Is that clear.

I am against putting a variable declaration in the for statement but I am all for putting a variable statement INSIDE a for loop.

Quote from Graham: "The ANSI standard is saying that declaring a variable in the control statement is functionally equivalent to declaring it inside the loop body. I find that quite reasonable."

If that's truth, I find it quite ridiculous!

If a variable declared IN a for statement has a defined scope, it is NOT the same scope as a variable declared INSIDE the for loop. It has got to be a scope bigger that the for loop scope and smaller than the scope of the function that it occurs in.

For one thing, variables declared WITHIN the for loop can NOT be used in the for statement.

For another, variables declared WITHIN the for loop may come into scope and out of scope (constructed and destructed) multiple times, and may also never even come to existence even once, depending on the condition of the for statement. While as variables declared in a for statement comes into scope exactly once, regardless of the for condition.

So a variable declared in a for statement is never the same thing as a variable declared within the for loop. They are not even close.

Commenting on "Item 32: Postpone variable definitions as long as possible."

That is a good rule only if you don't follow it to the extreme. I still prefer to declare any local variable at the top of the function body, rather than in the middle. There are two problems.

1. If you declare something in the middle of line, and later on you modified the code and you would suddenly find the need to move the declaration a few lines ahead. And this need may occur again and again until you finally give up and just put it at the beginning of the function.

2.When looking up where and how a local variable is declared, you have to look through the whole function body to search for it, while as I can immediately jump to the beginning of function body and find it immediately.

If you really need to limit the scope of a variable, I would rather put in an extra pair of {}, and declare the variable within the {}, at the top. Declaring a variable some where in the middle of code block and let its existence linger there until the the end of function call, that's really not something right to do.

In any case, if you feel that putting a variable declaration at the begnning of function call would make it too far away from where it is first used, and hence hurt readability, then the problem becomes that you have a function that is too long, and it is time to try to split it into several sub functions to reduce size of each function call.

Gawd, you do take the 'ump easily, don't you? I said "functionally equivalent". I was putting into English a sense of the formal statement used in the standard. Essentially, what I meant was that a variable declared in the control statement will (should!) die at the end of the loop processing. Yes, I know that there is a difference in that variables declared with the controlled body die and regenerate with each iteration, but the point is that the control-statement-declared variable should not have a lifetime to the end of the function. This might be important if, for example, you wanted to lock a resource for the life of a loop. Using VC++, you would have to put a superfluous set of braces around the loop, as you would if you declared the variable ahead of the control statement.

Code:

---

for (lock l, ... /* etc */)
{
    // whatever
}

---

would have to be:

Code:

---

{
    for (lock l, /* etc */)
    {
        // whatever
    }
}

// or

{
    lock l;
    for (/* etc */)
    {
        // whatever
    }
}

---

Now, anyone may argue that that's actually more explicit and therefore better. OK, that's a point of view. What is a point of fact, however, is that VC++'s interpretation of a piece of standard C++ is wrong/

Anthony, I don't suppose you learnt to program in Pascal by any chance? Your programming ideals seem to be in-line with a Pascal nature of programming (not that that is a bad thing). However, I do hasten to add that speed and program efficiency is of utmost importance in many resource sucking applications. People tend to use larger functions to avoid that heavy call overhead (as I'm sure you know). In such functions I personally don't see a problem with declaring the variable further into the function, to aid reading. Its just my personal preference to declare a variable where I use it. I think the main thing is that people should remain consistent in their coding, and so if you declare your variables at the beginning of a function block, then good on you, so long as you always do it.

Alan.

Sorry to again discuss the topic of C++ Standard and VC again, but according to Standard of C++ section 10.3.4 this is legal code of C++, i.e. different return type in function overriding, but VC 6 refuse to compile it

Code:

---

#include <iostream>
using namespace std;

class Base {
};

class Drive : public Base {
};

class base {
public:
        virtual Base* fun() { cout << "base" << endl; return 0; }
};

class drive : public base {
public:
        Drive* fun() { cout << "drive" << endl; return 0; }
};

int main()
{
        base* pbase = new drive;
        pbase->fun();

        delete pbase;
        return 0;
}

---

But at least VC.Net compile it. As far as standard is concern, VC.Net is much more better than VC 6.