Rating changes for last rounds are temporarily rolled back. They will be returned soon. ×

-is-this-fft-'s blog

By -is-this-fft-, history, 7 years ago, In English

#define rep(i, l, r) for ((i) = (l); (i) < (r); (i)++)

Things like that are pretty common. Why do so many of you need to do things like this? What is wrong with a good old for-loop? Is it that slow to write one explicitly?

  • Vote: I like it
  • +52
  • Vote: I do not like it

»
7 years ago, # |
  Vote: I like it 0 Vote: I do not like it

It's shorter.

  • »
    »
    7 years ago, # ^ |
      Vote: I like it 0 Vote: I do not like it

    So?

    • »
      »
      »
      7 years ago, # ^ |
        Vote: I like it 0 Vote: I do not like it

      Its just personal opinion I think.

      Some people are just comfortable using #define for for(;;). Others are not. There isn't much to it.

»
7 years ago, # |
Rev. 3   Vote: I like it 0 Vote: I do not like it

consider the two cases:

1) rep(i, l, r) — 12 characters

2) for (int i = l; i < r; i++) — 27 characters

The difference is a whopping 15 characters! The average typing speed is ~44 WPM or ~220 characters per minute, that's ~4s for 15 characters! Sure, it might not seem like a big number but over time it adds up. After you've written over 1000 for loops (not an unreasonable number, corresponds to ~100 problem solution) the saved time has accumulated to 4000s or around one hour! To get your imagination rolling, here is a list of 101 fantastic things you could've done in that hour: https://www.care.com/c/stories/5309/101-things-to-do-with-an-extra-hour/

  • »
    »
    7 years ago, # ^ |
    Rev. 2   Vote: I like it +4 Vote: I do not like it

    That's why I do "for<TAB>l<TAB>r<TAB>" — that's 8 keystrokes only. And I have the braces as a bonus!

»
7 years ago, # |
  Vote: I like it +139 Vote: I do not like it

To avoid this bug:

for (int i = 0; i < n; i++) {
  for (int j = 0; j < n; i++) {
  }
}
»
7 years ago, # |
  Vote: I like it +8 Vote: I do not like it

Actually all C-style for-loops are syntactically broken.

»
7 years ago, # |
  Vote: I like it +43 Vote: I do not like it

Less important reason (shorter code) was already mentioned few times, so I won't talk about it.

More important reason is that in 90% of usages there is a lot of redundancy within them which leads to being highly error prone. In

for (int i = 1; i <= n; i++)

you have to write "i" three times! In my macro version this is equivalent to RE(i,n) where i occurs only once. This way this is much less probable that I will make a bug when one of these three occurances is j or exactly what I_love_Hoang_Yen suggested. This is most vulnerable in cases where we want to change name of our variable and replace for example two out of three occurances. For example when I do n phases of my algorithm and use "i" to denote phase number and in every phase I iterate over all vertices of my graph which I also call "i". Then compiler tells me something about shadowing or maybe I simply use number of phase inside that inner loop and I am forced to change inner i to something else and I chose v. And I end up with

for (int v = 1; v <= n; i++)