[Development] How to port from Q_FOREACH to range-based for

Mutz, Marc marc at kdab.com
Tue Jun 11 20:47:12 CEST 2019

On 2019-06-11 09:48, Lars Knoll wrote:
>> On 11 Jun 2019, at 09:35, Olivier Goffart <olivier at woboq.com> wrote:
>> On 11.06.19 09:17, Lars Knoll wrote:
>>> So, is removing it worth all the hassle to us and our users? 
>>> Q_FOREACH is a macro and it doesn’t really cost us anything to keep 
>>> it around. Yes, it has issues with non Qt containers and I wouldn’t 
>>> recommend it for any new code. But maybe we could simply fix that 
>>> part, but making Q_FOREACH emit a compiler warning if used on a 
>>> container that’s not implicitly shared?
>> +1
>> Although we should probably still discourage its usage in the 
>> documentation.
>> Regarding the compiler warning:
>>  https://codereview.qt-project.org/c/qt/qtbase/+/244010
> Nice. So doesn’t this solve most of the issues we have with Q_FOREACH
> (maybe with the exception that some people find macros ugly)?

If you look at the git history, you will find that it's not at all 
maintenance-free code that just sits there. I just saw a C++17(!)-only 
code path there when I rebased my deprecation patch to current dev the 
other day.

There's also, as Peppe has repeatedly indicated (and never got a proper 
reply to) the teaching/documentation issue: as long as Q_FOREACH stays, 
undeprecated, we need to teach people about it: when to use and when not 
to use. That's usually 10min or so of an intro Qt course that could be 
better spent on teaching something more important.

If Q_FOREACH is deprecated, we can drop the slides, and a good chunk of 
the docs.

This is a bit like the Fridays for Future generation clash: the new 
developer asks "why is there Q_FOREACH if there's ranged-for?" and the 
older devs answer: "because I wants my SUV, erhm, I mean Q_FOREACH".


More information about the Development mailing list