View Single Post
Posts: 726 | Thanked: 345 times | Joined on Apr 2010 @ Sweden
#14
Originally Posted by attila77 View Post
Yes, it’s a macro construct/Qt extension.
Macros are nice things.

As for speed, that’s a bit more complex topic. Faster to code, certainly, but not only that. If you do a plain sequential benchmark, it *might* come out slower, but then we’re getting into deep water - by default foreach provides you with safety by making a copy of the container, so if you meddle with the content, you don’t trip over yourself.
Making a copy typically means calling malloc at least once per index making it slower than straight indexing. But it's a nice feature that helps to avoid typical coding errors, so, a good thing.

Now, if you’re NOT altering it, you can do foreach (const type &, container), which is roughly on par time-wise. Exact timings will of course depend on particular compilers. But at that point, you already have a flow that is very easy to convert to QtConcurrent::map, which (at least on the desktop, but soon on mobiles, too) unleashes all those sleeping cores and blows a simple ’for’ out of the water.
Concurrent handling of a short list might very well be slower than straight indexing if you take the thread creation cost into account. But, I agree on concurrent handling being faster on longer lists, no problem there.

Concurrent handling is something else than indexing of a collection but it was nice to get to know about how the const declared index parameter changes the behaviour. C++ is marvelously black magical.