On 08/06/2019 21:39, Konstantin Tokarev wrote:
What abouthttps://valdyas.org/fading/hacking/happy-porting/ "[...] none, not a single one of all of the reasons you want to deprecate Q_FOREACH is a reason I care even a little bit about. It’s going to be deprecated? Well, that’s a decision, and a dumb one. It doesn’t work on std containers, QVarLengthArray or C arrays? I don’t use it on those. It adds 100 bytes of text size? Piffle. It makes it hard to reason about the loop for you? I don’t care. What I do care is the 1559 places where we use Q_FOREACH in Krita. Porting this will take weeks. [...]" ?This kind of porting could be automated with clang-based tool, if anyone cared to make it. This tool could automatically use qAsConst/std::as_const for non-const lvalues and add temporary variable for non-const rvalues, without user even knowing what the hell are lvalues and rvalues and other things Marc writes about.
At the cost of saying for the 100th time, before this stuff ends up indexed by Google: you can port away from Q_FOREACH in an automated way only in trivial cases. *NOT* in the general case.
For the general case you've only got the 5 minutes solution (c&p&rename Q_FOREACH into your codebase; assuming the worst case, of lack of "Qt5Support" or so) or the long walk of checking all usages.
HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
