Re: position of vector declaration
sergiopeffe-news@yahoo.it wrote:
I am puzzled by a message in my compiler (visual c++ 8)
This is the smallest fragment that shows the problem:
#include <iostream>
#include <stdlib.h>
double currentVal[3];
int main(void)
{
for (int i = 0 ; i < 10 ; ++i)
{
double oldVal[3]; ///--------IS THIS DEFINITION CORRECTLY PUT?
If the variable is only used in the for loop, yes.
//in the real application the current val vector is computed in
some way...
//here I simulate
for (int j = 0 ; j < 3 ; ++j)
{
currentVal[j] = (double)rand() / RAND_MAX;
}
if (i != 0)
{
//not first pass
std::cout << "old Val: " << oldVal[0] << " " <<
oldVal[1] << " " << oldVal[2] << std::endl;
//doSomethingWithCurrentValAndOldVal();
}
//now I copy currentVal in oldVal
memcpy(oldVal, currentVal, sizeof(oldVal));
} //-----------it seems that here, in visual C++ 8, the oldVal
//-----------goes out of scope
As it should. This has always been the case, from the earliest
days of C. I can't imagine a compiler not getting it right.
return 0;
}
This program is compiled correctly, but when I run it I obtain
a message that says that oldVal (in the cout statement) is
used without being defined.
Without being initialize, I suppose you mean. That's the case,
although hat's off to VC++ for actually detecting it.
Stepping in debug it seems (as I wrote in the comment) that
oldVal goes out of scope when the program ends a cycle of the
for.
That's what the standard requires.
Putting oldVal outside the for is ok, but I am puzzled because
I thought that variables could be defined in the for statement
and they are valid throught it, from begin to end of the for,
not only for one iteration only.
For historical reasons, the rules are somewhat complex (although
not outrageously so), but the effect, at least for variables
defined within a function, is always that the variable has the
scope of the nearest statement which encloses it. The "int j"
in your code has the scope of the for loop, because it's
definition is in the for. In the case of oldVal, on the other
hand, the nearest enclosing statement is the compound statement
controled by the for. This statement is entered (and left) each
iteration through the for.
The same program, in Dev-c++ 4.9.9.2 runs fine.
No it doesn't. The compiler just doesn't do enough checking to
catch the error. So you get whatever happened randomly to be in
the array before. In practice, in such a simple example, it's
hard to imagine that being anything other than what was in the
previous array---I can't think of an allocation scheme for local
variables which would not have oldVal always at the same address
(although this is certainly not required by the compiler).
Replace double with a type with a constructor and destructor,
and you'll see that they are called each time through the loop.
Replace double with std::string, for example, and oldVal will
always be full of empty strings.
Of course, you'll want to replace memcpy with std::copy as well,
if your types have constructors. But then, this wouldn't be a
bad idea anyway.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]