[Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)
Giuseppe D'Angelo
giuseppe.dangelo at kdab.com
Wed Mar 24 17:05:50 CET 2021
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 do
>>
>>> QSet 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.dangelo at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20210324/788e0995/attachment.bin>
More information about the Interest
mailing list