Re: Variables in for loop (style issue)

Carlos Moreno wrote:
  > Maciej Sobczak wrote:

      [...]
  >> The point is that the only reason to call some function twice
  >> is to express the fact that it might not return the same
  >> value twice. If you know that the function is going to
  >> return the same value, then calling it more than once is just
  >> sloppy. IMHO, of course.

  > We seem to disagree in there -- if you compute the square root
  > twice, do you expect to obtain a different result the second
  > time?

Presumably, Maciej wouldn't call sqrt twice with the same
argument. Also, I think we should accept that he is a
reasonable person, and is only considering a limited locality; I
don't believe that he is suggesting that we should avoid calling
sqrt(2.0) twice in a program of a million or so lines -- simply
that in his opinion, within a single (small) function, it makes
more sense to call it once and cache the return value, rather
than to call it twice. I don't agree with him, but I'm not
going to try to force him into an exagerated position just to
win my argument.

  > The fact that if the function could return different values
  > for different calls means that *you must* call the function
  > again does not mean that if you call the function again is
  > *because* the result is going to change -- I know that this is
  > not what you're saying; my point is, I don't see a reason to
  > *expect* that the function could return a different size. Not
  > in a simple and straightforward situation like calling size()
  > for a container.

  > Let's put it this way: if the setup line of a for loop is
  > what tips you about a container changing its contents, then
  > there is something severely wrong with that code (or with that
  > coding standard).

Let's put it this way: when you're dealing with STL containers,
you simply have to know. And there can be lots of conflicting
signals: the fact that he is using indices, and not iterators,
for example, could in some contexts suggest that the container
is modified (in a way which would invalidate the iterators).

  > There *must* be much more important clues about that, since it
  > is an event of monumental importance (compared to calling
  > v.size() more than once -- such a trivial thing being the
  > giveaway for such a monumental event tells me that there's
  > something wrong with the code).

  > There's also the fact that if you "cache" the value of the
  > size, then I'd be really worried about the body of the loop,
  > unless the compiler enforced constness -- caching the value of
  > size() *relies* on the vector's size not changing; calling
  > size() many times work in all cases. Why would I try to avoid
  > the solution that works in all cases without sacrifice of
  > efficiency and arguably without sacrifice of readability?

So you don't use iterators. vector<>::iterator counts on the
vector's size not increasing.

I agree with you that leaving the call to size() in the for
isn't a sufficient enough signal that the value might change.
On the other hand, I don't really buy the argument about leaving
it there for reasons of robustness -- the same reasoning would
have us ban the use of iterators.

In the end, it is a style issue, and opinions may vary. I
prefer his first version because I find it more concise, and at
least as clear as, if not clearer than, the other alternatives.
He finds it less clear (I don't think you can argue the
conciseness), because it leaves open the question of whether the
size of the vector changes or not. I disagree, because I think
that as signals go, this one is too subtle, and also, because it
only works in a few, very special cases and because I imagine
that the information is generally fairly evedent anyway, if it
is needed. I might add that I don't think it is a generally
recognized signal -- but local coding standards could affect
that.

--
James Kanze kanze.james@neuf.fr
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! ]