[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