[Development] On deprecated APIs

Ulf Hermann ulf.hermann at qt.io
Wed Aug 31 11:27:20 CEST 2016


> 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



More information about the Development mailing list