Re: Variables in for loop (style issue)
Maciej Sobczak wrote:
Consider this:
for (size_t i = 0; i != v.size(); ++i)
{
// do something with v[i]
}
The above is considered to be a bad practice, because it calls
v.size() every iteration and sugggests that the size of the
vector might change, which is actually not the intent.
Are you kidding? The first and most important rule is the KISS
rule. Don't add unnecessary complication. The simpler the
better. I'd use an iterator rather than an index if I didn't
need the index in the loop, and I'd use an algorithm rather than
a loop if there was a suitable one available.
The possible solution (and even stated as a rule in one coding
standard) is:
const size_t vSize = v.size();
for (size_t i = 0; i != vSize; ++i)
{
// do something with v[i]
}
The above, however, breaks another coding standard rule saying
that variables used to control the loop should be declared in
the scope of the loop without polluting the enclosing scope
(that's what the scoping rules in for are about, right?).
So you've got a broken rule. If (and only if) the profiler
shows that you cannot afford the call v.size() each time through
the loop, you use this idiom.
The other solution might be this:
for (size_t i = 0, vSize = v.size(); i != vSize; ++i)
{
// do something with v[i]
}
But this, in turn, breaks another coding standard rule saying
that everything that could be const must be const (above,
vSize cannot be const, because it's declared together with i
as non-const size_t).
It also breaks the usual rule against declaring two variables in
the same statement. I know that I have trouble reading such
things, and I imagine that others do as well.
The ultimate solution might be this:
{ // artificial enclosing scope
const size_t vSize = v.size();
for (size_t i = 0; i != vSize; ++i)
{
// do something with v[i]
}
}
But it smells unpleasantly because of this additional pair of
braces and the resulting indentation.
Unnecessary complication, for no gain.
There are special cases where an extra pair of braces to control
lifetime are justified. I do it a lot in unit tests, for
example (and every unit test framework I've seen seems to do
so), and I do it at times with older versions of Sun CC (which
don't support the standard lifetime of temporaries). But it
takes some justification, and there isn't any here.
Conclusion [*] - there's no way to do it *right*.
I fail to see any problem with your first suggestion. It's what
I use, and it's really the only variant I've ever seen in actual
code. It's the easiest to write, and the easiest to get right;
anything else is just extra work -- even just thinking about the
issue is a waste of time which could be more productively spent.
--
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! ]