This is a debate convenience vs performance;
* Q_FOREACH will never detach, hence it is convenient.
* A for-loop can be (a very little more) optimized, as long as you work
on const containers or use qAsCont (and many will forget about that... which
is *not* convenient)
... especially as there is no qAsConst() for containers returned from
functions. Those have to be saved in a local variable first, which makes the
code not only less convenient but also uglier.
I understand that we should teach people to avoid premature pessimzation, but
at some point the pessimization might not actually be premature anymore.
Q_FOREACH always makes a copy. This means you cannot mess up the logic if you
change the code to modify the container in the loop body. You might actively
decide to take a small performance hit for the convenience of not having to
take care of this every time you change a loop body.
The rules on when a Q_FOREACH detaches an implicitly shared container are also comparably simple.
If you take a non-const reference as "iterator", then it detaches. If the reference is
const or if you iterate by value, it won't detach. The rules in the "ranged for" case are
more complicated and the user might actively trade a small performance hit for the ability to see
the detaching behavior on first glance.
Those are valid tradeoffs to be considered by the users and we should not
impose either solution on them. So, I think there is still a place for
Q_FOREACH in user code and we should not deprecate it in the first place. I
agree that it's a good idea not to use it in Qt code.
regards,
Ulf
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
