markg added inline comments.
INLINE COMMENTS
> graesslin wrote in pointer_input.cpp:440
> > Just curious, why do you define end as opposed tho this:
>
> Because @broulik tends to point out that it is not cached.
>
> > Another route you can go which looks much cleaner imho (requires Qt 5.7
> > because of qAsConst):
>
> does that work in a sensible way for a QHash? The most lean way would have
> been:
>
> if (std::any_of(m_buttons.constBegin(), m_buttons.constEnd(), [] ...))
>
> But that doesn't work with QHash. So I kind of doubt QHash and qAsConst do
> something sensible.
This is where STL and Qt apparently diverge a bit.
for (auto value : qAsConst(m_buttons)) {
// ...
}
Gives you the values in the map. Not the keys. And that is because it's a QHash
container which apparently behaves like that.
If it were an std::unordered_map it would have given you a std::pair where
first would be the key, second would be the value.
However, in *this* case you are only using the value thus you are fine when
using:
for (auto value : qAsConst(m_buttons)) {
// ...
}
Since you seem to mention optimization (you shouldn't have done that ;)), this
is the most efficient version, and i looked it up [1], hehe:
for (cont auto &value : qAsConst(m_buttons)) {
// ...
}
In fact. You likely always want this version of the range-based-for loop. And
"for (auto&& value: ...)" if you want to modify them in place. You nearly never
want a plain range-based-for without a reference symbol in there because that
makes a copy.
Hope that helps :)
[1] Read
https://blog.petrzemek.net/2016/08/17/auto-type-deduction-in-range-based-for-loops/
for the details
REPOSITORY
R108 KWin
REVISION DETAIL
https://phabricator.kde.org/D5461
To: graesslin, #kwin, #plasma
Cc: broulik, markg, plasma-devel, kwin, spstarr, progwolff, lesliezhai,
ali-mohamed, hardening, jensreuterberg, abetts, sebas, apol
