Fixed nit, now using C++11 iteration loop style.

move those functions into libconsensus later

Concept ACK on doing required trivial refactors before moving chunks of code.

I'm doing a big PR on #8339 that is still work in progress.
My goal is to make it smaller by doing trivial stuff I come accross while doing it, then I will rebase on top of it.

utACK 4358252

@dcousens updated the commit, I forgot GetLegacySigopsCount

Concept ACK on doing required trivial refactors before moving chunks of code.

Why is that? Why can't #8329 , for example, happen before this?

Regarding the PR, I would prefer to move to plain C fors to move towards C rather than towards C++11 (I mean for libconsensus code only). But I don't care enough to nack.

I would prefer C++ 11, only because I'm a spoiled kid using high level language like C# and even with C++11 I feel at the stone age. :(

I don't think it make sense to move something in consensus/* which can't yet be compiled into libconsensus. But I'm not feeling strongly about it neither.

Why is that? Why can't #8329 , for example, happen before this?

Haven't seen the other pull is already open. I have no strong opinion on which should go first. My comment was meant as a general guideline in case the more disruptive pull may not be uncontroversial enough to merge immediately and the trivial improvement can go in right now. Also note that the plan was to get rid of some boost stuff in 0.14, anyway. _{We could even do the replacement for the whole file ... hides .}

Oh, personally I like the new loop more, and I'm very used to classes. Most of my experience is with C++, java and python, not C. But apparently some analysis tools are much more mature for C than for C++ and we could potentially benefit from them for consensus code if it was C. Maybe @gmaxwell can say more about this. In any case, was not a nack.

@MarcoFalke well, I was asking on the general guideline. It makes sense to open both options because we don't know what's going to be merged first. That's what I've been doing so far: any changes after a moveonly have been mostly ignored and the moveonlies themselves, separated or not, have been delayed forever. With the exception of this PR and #8341 all "dumb fixes" have been already done.
We need to make new consensus functions to be populated with code from main, mostly from connectBlock. But those functions will need to call existing consensus functions. Therefore either we move before doing that or we introduce a circular dependency between the new consensus file and main that won't be resolved until the existing consensus functions are moved out of main.
Plus people would have a place to write new consensus functions like, say SequenceLocks() better than main.
Sorry, maybe we should discuss this in #8329

@jtimon there is so much that would have to change to make libconsensus C only. This for-loop change does not change that in any way.
If a dedicated effort begins, when libconsensus is actually separated, to make it solely C, I'm sure these loops will be the simplest to change.

@dcousens agreed, while we keep adding classes to the consensus code, these lines are not a concern. I still would have preferred to do this with the old style loops ages ago.

utACK (and don't mind using auto where @paveljanik suggests)

This for loop cannot be C period - it's using classes. C++11 loops make sense.

@paveljanik good catch, I just updated commit to use auto everywhere.

ACK a3e1984

ACK a3e1984

Upgrade from non-nack to utACK a3e1984

utACK a3e1984

@jtimon We've switched the project to c++11 just so that the code can use c++11, please don't come up with any lousy excuses not to. If you want to port the consensus code to some other language later that should not affect how development is done in this project.

utACK a3e1984 (after .13 split-off)