[Development] Qt 5 types under consideration for deprecation / removal in Qt 6
giuseppe.dangelo at kdab.com
Mon Jun 10 12:10:45 CEST 2019
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.
Giuseppe D'Angelo | giuseppe.dangelo at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4329 bytes
Desc: S/MIME Cryptographic Signature
More information about the Development