10.06.2019, 13:10, "Giuseppe D'Angelo" <giuseppe.dang...@kdab.com>: > 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.
How is one supposed to port uses of Q_FOREACH in 1559 places then? > > 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. What things should be checked during that "long walk", except aforemention measures to avoid detaching? If we cannot have porting tool, we need at least comprehensive porting guide (and if such guide is formalized, I'm pretty sure it will be possible to automate it, at least partially) -- Regards, Konstantin _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
