Added some breaks to some BOOST_FOREACH #1735

After the first time the if is true, it's quite useless to check the other nOffset of vSorted.

LGTM but you should rebase so there isnt 5 commits

Indeed, this doesn't need three commits and two merges.

Does this actually result in different code? The loops have no real side effects, I don't know how terribly the boost foreach is, but it's not inconceivable to me that the compiler could already do this with these loops because they're simple single assignment.

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/bbcb74effad812ebf418627133341ba05e373b95 for binaries and test log.

Would be ok with me if rebased into one commit

I don't like these kind of obsessive-compulsive source code changes, I think they're a waste of time.

If you're rewriting old code for some reason, then feel free to clean it up. Otherwise I think it is better left alone.

Agree that it does smell like premature optimization, with zero proof of actual need or benefit

The objective isn't only a (probably null) optimization. I see it as "let's make it clear what is the meaning of the code". Is it "looking for at least one element with a condition" or is it "using an hidden side-effect of enumerating the collection/checking the condition"? The first time I watched the code I asked myself: why isn't it breaking if it is only looking for a single value?

For the rebase... I'm a noob of git... This evening I'll try to do it.

Rebased (I hope... In the end after fighting with the rebase -interactive I installed the TortoiseHg and, after fighting against its rebase I used the reset command)

It's still adding source code and binary code size without much benefit. We definitely appreciate people reading the source codebase this closely, though! It is this kind of attention to detail that benefits all bitcoin users.