Maybe the wording is wrong... how about "not recommended" instead of "deprecated"?
I would also like to have an option to be able to compile a "qforeach" block without the compiler spitting at me (/me takes off the java developer hat). On Wed, Aug 31, 2016 at 12:27 PM, Ulf Hermann <[email protected]> wrote: > > 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 >
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
