dfaure added inline comments. INLINE COMMENTS
> svuorela wrote in dialog.cpp:317 > I think I read once that whenever you used a ordered map over an unordered > map, you need to justify it by talking to your manager about it. But that's > also a bit from the bucket of nitpickery unless we are in a hot codepath. Interesting. This makes it sound like "ordering" is a feature that costs extra. But my understanding is that the bookkeeping required for a hash table, is what costs extra -- for small quantities of data, as is the case here. Instanciating nodes and making a few '<' comparisons are less work than creating buckets, and hashing (entire) strings. Anyhow, for 5-10 items nothing makes a difference. > svuorela wrote in dialog.cpp:326 > nitpickery. but range based for and qAsConst on container? For a QMap? I think this iterates over pairs, so it only looks nice with C++17 structured bindings. (or if it doesn't, then that's an incompatibility with std::map, awful). REPOSITORY R295 KCMUtils BRANCH fix_duplicates REVISION DETAIL https://phabricator.kde.org/D28760 To: dfaure, apol, broulik, davidedmundson, kossebau, svuorela Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
