Hi, On 24/03/2021 15:57, Matthew Woehlke wrote:
...we might not be having this conversation.
Sure. I don't get called to make *that* decision, though. So I also had to live through that.
I've proposed helpers and cleanups for 5.15/6.0 and those didn't land due lack of time or API/ABI constraints. What else can one do?
We're not talking about adding many, many variations upon this theme, just*not* removing the ones that already existed. The ones that do exist, exist because they are more convenient to use, and because they cover*the most common* use cases.Can I hear some use cases then please? Because from the experience of usages within Qt, it was a nail/hammer problem, call it an education problem ("I know containers; I don't know algorithms; let me use containers to solve an algorithmic problem"), of which we're entirely responsible (Qt docs teach a lot about containers, but not about algorithmic design.)An example I know offhand: https://github.com/Kitware/qtextensions/blob/0ff5b486f08435c8cdfbc9f05d2f104f63b16aed/util/qtUiState.cpp#L268 Yes, in fairness, using a set to de-duplicate is arguably an algorithm problem. OTOH, I'm not sure I really want to trade hashed lookup for generating a collection of an unbounded number of duplicates. Also, yes, most programmers probably don't know offhand how to de-duplicate a collection using algorithms. (I'd also want to see performance numbers that the latter approach is actually more efficient, because offhand I'm not*at all* convinced it is, and wouldn't be surprised if it's*worse*).
You could, however, package that algorithm and hide the implementation. Maybe provide the bounded and unbounded versions so the caller can choose depending on some information they have. Maybe provide a version using monotonic PMR if the caller knows that the number of elements is going to be relatively small most of the time.
For your particular implementation, to give you another "interesting" datapoint, none of the code you're using is even particularly optimized (as it COULD be) within Qt itself. QSet::operator+=(QSet) doesn't splice from the argument if it's an unshared rvalue (whops!). Even the goodwill of using containers as algorithms gets sabotaged by the poor implementation.
(An incredibly better solution would already to be unordered_set and its ranged insert. But then 1) if you didn't package it now you have to change all over the place instead of once, and 2) obviously you don't have unordered_set::toList(), WHOPS!).
The reality is that using containers to solve algorithm problems (e.g. "I'm using a map because I need the values to be sorted") is extremely common.
Then we're spectacularly failing at educating users, to be honest.
* I need to keep the list, process it in order, but avoid processing duplicate elements; 99% of the time the list is a handful of elements; let me doQSet s; for (elem : list) { if (!s.contains(elem)) { s.insert(elem); process(elem); } }And what, exactly, is the solution here?
KDToolBox::DuplicateTracker, courtesy of Marc.
* I've got a square peg (a QList) and a round hole (an function I made that takes a QSet), so I need conversions to call it.And what, exactly, is the solution here? Probably "ranges", but those aren't available yet.
Not an easy answer, but maybe start not to have functions take/return specific containers.
Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
