Re: Variables in for loop (style issue)
Carlos Moreno wrote:
Call an STL or STL-like algorithm -- when you see something like
count_if (v.begin(), v.end(), ...), you get the best of *all* worlds;
the call tells you that the size will not change (it strongly suggests
it, at the very least, even if it doesn't enforce it); it tells you
about the intent to count things (as opposed to something else, and
without the need to resort to high-level algorithm analysis to see
what's going on); and last, but not least, you do not evaluate
v.end() or v.size() with each pass of the loop. Talk about best
of all worlds.
Of course, this is good approach. At least in those cases where the
"doing" part of the loop can be provided in a way that does not qualify
for the obfuscated C++ contest. :)
Conceptually, the for loop is something that tells you, up front
and directly, how many times the loop will execute. If the vector's
size can change, then we do not know how many times it will execute
from the header of the loop, and hence it should probably be a
while loop.
This is reasonable. In fact, it could be part of yet another coding
standard. :)
Anyway, how many *reasonable* examples do you have of well-written
code with a loop written like "for (int i = 0; i < v.size(); i++)"
where the vector's size changes?
I have it in one of my projects. The body of the loop is extremely
simple, just one-liner that calls the member function of the object
pointed by pointer stored in the vector:
for (...)
{
v[i]->foo();
}
The fun is that the referenced objects are polymorphic and the function
being called is virtual. This means that the actual work that is
performed is not stated locally (in the source code sense) and actually
one of the derived types adds more "job elements" to the vector by means
of push-back. The result is that the vector *can* change its size and
it's not immediately clear from the body of the loop. I have therefore
expressed this fact by calling v.size() every time. Contrary to this,
other loops express different (more strict) intents and are coded
differently (in more strict way).
So - this is not a pure theoretical stuff, at least in this project.
In the sibling post James wrote:
In the end, I think that the question only really becomes
relevant when you know why the loop is there -- what its role in
the algorithm is. And once you know that, you probably do know
whether the vector changes size or not, independantly of where
the call to v.size() is.
This is very important point. On the other hand, just knowing what is
the purpose of some function/object/etc. in the program does not relieve
me from the obligation to give it a name that best communicates its
purpose. Function named "f" might not be the best choice even if
everybody in the room knows what this function does - similarly with
control constructs and other parts of the program: the more they
communicate, the easier they are to interpret, by both programmers and
automated tools.
And in the context of automated tools: note that making the idiomatic
distinction between different forms of loops makes them easier for
static analysis. The fact that programmers use a lot of knowledge that
is not formalised in the code and is only "flying in the air" does not
make it any better for the static analysers.
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]