autotests: Port away from foreach loops over members without calls to owner
ClosedPublic

Authored by kossebau on Sep 3 2019, 1:23 PM.

Diff Detail

Repository
R39 KTextEditor
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
kossebau created this revision.Sep 3 2019, 1:23 PM
Restricted Application added projects: Kate, Frameworks. · View Herald TranscriptSep 3 2019, 1:23 PM
Restricted Application added subscribers: kde-frameworks-devel, kwrite-devel. · View Herald Transcript
kossebau requested review of this revision.Sep 3 2019, 1:23 PM
cullmann accepted this revision.Sep 3 2019, 2:36 PM
cullmann added a subscriber: cullmann.

ok

This revision is now accepted and ready to land.Sep 3 2019, 2:36 PM

thought not sure why a range based for doesn't work on the m_codesToSpecialKeys stuff with qAsConst. But I assume that has some reason and it is just testing code anyways.

kossebau added a comment.EditedSep 3 2019, 2:43 PM

thought not sure why a range based for doesn't work on the m_codesToSpecialKeys stuff with qAsConst. But I assume that has some reason and it is just testing code anyways.

There the new code was motivated bye the use of both key & value of the m_codesToSpecialKeys map.

I would have thought you could use the it.value/key stuff with the range based for, too, but I must confess I mostly use stl containers with for, perhaps mistaken.

I have never seen a range-based for loop with qmap/qhash. But then I also only now learned about the existence of QKeyValueIterator being triggered by your question :)

Looking further, given the definition of range-for, for what I understand, we are still out of luck when it comes to QMap/QHash, as the begin_expr and end_expr are expected to be begin() and end() for classes, which for the Qt hash containers are bound to the value iterators. So to my best knowledge and experimenting, not possible.
If anyone reading this can tell better, please do, learning all the time.

:=) I have no idea, I hope future Qt versions are there more consistent with STL, which I prefer.
Please push this as is, at least we are away from Q_FOREACH.

This revision was automatically updated to reflect the committed changes.