[Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
Thiago Macieira
thiago.macieira at intel.com
Thu Sep 21 02:28:05 CEST 2023
On Wednesday, 20 September 2023 07:35:24 PDT Marc Mutz via Development wrote:
> But, as mentioned in this thread some weeks ago, we're currently lacking
> public efficient API for "op== with Qt::CaseInsensitive". For the same
> reason we need equal^WcomparesEqual and can't rely solely on
> order^WcompareThreeWay, we need a standard way to have parametrized
> checks for equality. I was also mentioning fuzzy comparisons for FP
> types. Yes, we can again add QString::equals(), with the same problem
> for both non-generic and generic code as with the current
> QString{,View}::compare(). Or we use equal^WcomparesEqual overloads with
> additional arguments and a kernel for qComparesEqualMulti that does the
> moral equivalent of
>
> using Qt::equal;
> if constexpr (qxp::is_detected_v<equals_compatible_with,
> decltype(lhs), decltype(rhs), decltype(extraArgs)...)) { // for each
> subset of extraTypes...
> if (!equals(lhs, rhs, extraArgs...)) return false;
> } else {
> if (!equals(lhs, rhs)) return false;
> }
> }
Sorry, I don't think we need any of this.
Case-insensitive comparison is rare. It's expensive and must be used only
where necessary. And more importantly, it's done ONLY with QString or maybe
its Views, so there's no need to go generic. There's no case-insensitive
comparison of Pixmaps or floating point.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5152 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20230920/9a4e5ab4/attachment-0001.bin>
More information about the Development
mailing list