Re: [Development] char8_t summary?
On Monday, 15 July 2019 09:41:24 PDT Matthew Woehlke wrote: > Note also that I suggested having the template definition out-of-line; > it doesn't need to be in (e.g.) qstring.h or anywhere that will affect > *user* compile times. Only the TU responsible for instantiating them > would be affected, and that should be negligible in the grand scheme of > things. Then it's no different than an overload, if the implementation isn't the same (and it isn't). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] char8_t summary?
On 14/07/2019 02.28, Mutz, Marc via Development wrote:
> If you're still not convinced, here's QStringView::endsWith() as a
> template:
>
> template
> requires std::is_convertible_v Qtf8StringView, || ... QLatin1StringView ...
> Q_ALWAYS_INLINE
> bool endsWith(Prefix ) const {
> return QtPrivate::endsWith(*this,
> QtPrivate::qStringLikeToStringView(p));
> }
>
> with a qStringLikeToStringView() similar to the one in 181620. This uses
> C++20, and I'm sure it loses something over the current implementation.
> Qt::CaseSensitivity comes to mind.
...and I don't know why you didn't just propagate through the case
sensitivity argument?
> To anyone speaking up in favour of
> the box: Please write this in C++11 before you hit reply :)
IIUC, replacing the `requires` is trivial. A bit ugly, sure, but not
difficult.
I also question the value of the indirection in the above. Moving the
implementation of QtPrivate::endsWith to be inline, and making use of
`if constexpr` where useful, will hopefully reduce the total amount of
code. (Yes, eventually you're going to have an optimized string
comparison. Helper code like that to implement the critical code paths
will still exist, but hopefully those are bits that get used over and
over in many methods.)
Note also that I suggested having the template definition out-of-line;
it doesn't need to be in (e.g.) qstring.h or anywhere that will affect
*user* compile times. Only the TU responsible for instantiating them
would be affected, and that should be negligible in the grand scheme of
things.
BTW, I don't think ternary functions are an issue. The ones that come to
mind will "always"¹ need to convert one of their arguments anyway, so
while the *templates* may involve another level of combinatorics, that
level won't affect the implementation complexity in any meaningful way.
(¹ Possibly they can skip this because that argument is never actually
used, but otherwise it must be converted.)
--
Matthew
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] char8_t summary?
On 13/07/2019 21:39, Volker Hilsheimer wrote: With an (ideally) single template-based API we don’t have peopleusing Qt get lost in the jungle for overloads and string classes. For the implementation, we can specialise the templates to call the suitable internal functions that implement the various algorithms. This is basically a Qt 7 idea, raised some time ago: a string class that is a collection of code points under "some" Unicode encoding, transparently wrapping UTF-8 / 16 / 32 sequences without extra copies. Functions between these strings dispatch to the right overload, in a manner that is totally invisible for the user. Similarly, the high level API works in terms of code points, not units. Only if one wants to get the hands dirty then one can query and extract the actual encoded data. My 2 c, -- 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 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] char8_t summary?
On 13/07/2019 15.39, Volker Hilsheimer wrote: > As I understood the template suggestion, it’s more about not having > to add 64 different overloads (or several more string classes) to > the Qt API, and less about unifying all implementations into a single > set of algorithms. Right. At some point you are going to call out to specialized functions (e.g. qt_compre_strings as Marc mentioned). The thought was to have a (more modest) set of these specialized helpers with the generic bits implemented as template logic. Probably with a bunch of `if constexpr` branches to perform optimizations when possible. > On 13/07/2019 07.41, Thiago Macieira wrote:> Again, note how the template > implicitly assumes things. A 3-character string >> cannot be present at the beginning (startsWith), end (endsWith) or anywhere >> in >> the middle (contains, indexOf, lastIndexOf) of a 2-character one, for >> example. >> >> But a 2- and 3-byte UTF-8 string can be the prefix of a 1-character UTF-16 >> string and a 4-byte UTF-8 string can be the prefix of a 2-codeunit UTF-16 (1 >> character). The correct fix for that is to count code points, not characters. Possibly this means that such optimization should be behind an 'if constexpr' to only use it when it is safe to do so. -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Kavindra Palaraja for approvership
On Thursday, 11 July 2019 17:27:29 CEST Paul Wicking wrote: > I’d like to nominate Kavindra Palaraja as approver. +1 - Paul ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
