## Re: [Rosegarden-devel] Subgroups latency compensation off by one

 Re: [Rosegarden-devel] Subgroups latency compensation off by one From: Chris Cannam - 2013-04-19 08:53:47 ```On 19 April 2013 06:37, Holger Marzen wrote: > On Thu, 18 Apr 2013, D. Michael McIntyre wrote: > >> Probably because there are tons and tons of situations in STL and Qt >> where standard idiom is to iterate through container classes with >> iterators, and the standard language is >> >> for (some_class_iterator i = some_class.begin(); >> i < some_class.end(); ++i) { ... > > Yes, that's what I think. But then we have tons of logical inaccuracies > because we don't see "i < some_class.end()" but "i != some_class.end()". That's the normal idiom when using iterator objects, because although they are comparable for equality, they aren't always comparable for ordering (in other words, there is not necessarily any operator< defined). Think about two arbitrary iterators pointing into a hash table, for example -- although you can easily determine whether they're the same, you can't quickly determine which one appears first in the table. Michael's use of < instead of != above was probably itself a typo, in other words, although not one that matters hugely (it would either work properly or fail to compile). Note that there is no semantic difference between ++i and i++ in this context either -- not in C++ and not in C. Both of them have the same effect, which is to increment i, even though they return different results -- and in the context of a for loop as above, the result is not used for anything so the difference is irrelevant. That is, the ++i in for (i = 0; i < 10; ++i) says "increment i, return the incremented value, and do nothing with it because it's not assigned to anything". The net result is simply to increment i. While the i++ in for (i = 0; i < 10; i++) says "increment i, return the value before it was incremented, and do nothing with it because it's not assigned to anything". The net result is again simply to increment i. Some old-school C programmers would write ++i instead of i++ here because it was theoretically faster to compute -- it just meant increment a value instead of having to copy, increment, and then return the old value. Of course in practice, every C compiler would optimise this so that the two were the same so the distinction was irrelevant. With the advent of container iterators in C++ the difference became theoretically interesting again, as potentially copying and incrementing an iterator could be more expensive than doing the same with an integer or pointer. Again, in practice it's not going to matter by now, but conversely, why would anyone write "i++" when it means the same as ++i but is more semantically complex and has the potential to be slower? Chris ```