On 24/03/2021 09.46, Giuseppe D'Angelo wrote:
And anyways these methods are still fully supported within Qt 5.
Tell that to all the people that compile with -Werror. Or just want
their code to compile without being full of warning spam.
"Just ignore it" may not be an option; sometimes there are *policies*
that preclude this.
...And, again, even that would be less of an issue if it didn't require
different code to support 5.14 and 5.15.
Yes, it does not generalize to every possible container type, but I
don't know that anyone is asking for that (and I agree we shouldn't try
to support that).
All the contrary, this is one big crux of the problem: toX() for a
completely arbitrary closed set of X is bad API. Why QSet::toList and
not toVector? Why QList::toSet and not, say, MULTI sets?
Because history. If you want those, do them the "right" way. Meanwhile,
don't "break" existing code.
Again, I think a lot of the reason folks are making such a big stink is
because we had:
5.14: toSet() is fully supported, no alternative is available
5.15: toSet() is deprecated, use ...
6.0: there is no toSet()
If things had *instead* looked like:
5.9: toSet() is fully supported, "better" alternative is available
5.12: toSet() is deprecated, "better" alternative is available
5.15: same as 5.12
...we might not be having this conversation.
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*).
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.
Ranges will fix some, but not all, of this.
Miscellanea examples from Qt itself,
* I need to remove duplicates from my list, let me do:
list = list.toSet().toList();
Right. Although note that the above example is doing a multi-merge with
de-duplication, so the "use a set as an intermediary" approach has a
better chance of being more efficient, since each merge will never
result in duplicates existing in the collection in the first place. I
agree that the above example is probably not optimal.
In any case, I'm not convinced that removing API is the solution to this
problem. It seems more like something for clazy to complain about.
* 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 do
QSet s; for (elem : list) { if (!s.contains(elem)) { s.insert(elem);
process(elem); } }
And what, exactly, is the solution here?
* 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.
--
Matthew
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
