[Development] Feature Freeze Exception: QStringView
abbapoh at gmail.com
Tue Jan 31 10:55:52 CET 2017
What about QByteArrayView? Do you plan to use std::string_view instead?
What about toInt/toDouble/etc, toLower/toUpper, right/left/mid (aka
std::string_view::remove_prefix/suffix), find and other QString methods
that doesn't modify the string? Do you plan to add them later or support
only small subset of operations (similar to std::string_view?)
Or maybe i miss some commits?
2017-01-30 22:03 GMT+03:00 Marc Mutz <marc.mutz at kdab.com>:
> QStringView is ready to be merged, but the maintainer has asked for another
> week before he can properly review the class.
> In case you don't remember, here's the discussion thread from 2015:
> Here's the evolving patch series:
> I feel the patch addresses all concerns raised in the discussion:
> 1. size_type: we agreed on on ssize_t equivalent to strike a balance
> the Qt preference of 32-bit signed types over the STL preference for
> unsigned types.
> 2. Do this in Qt vs. do this in QtCreator. I believe that a QStringView
> without deeply-routed support in QString would be a still-born. We also
> don't have time come Qt 6 to port all of Qt to a QStringView developed
> elsewhere. The current patches just scratch the surface. Everywhere
> QStringRef is currently used, QStringView can be used. And a lot of
> that traditionally only took QString should take QStringView, too, e.g.
> QFile::encodeName(). So I added it to Qt.
> 3. Keeping existing QString overloads for implicit sharing.
> The patch does not remove anything. It will, as it progresses, implement
> QT_STRINGVIEW_LEVELs 2 and 3 which remove existing QString and
> overloads (2: only where the function read from the string, 3: also
> it stores the string), so that at some later point in time we can just
> a preprocessor switch and compare executable size and execution speed of
> both sets of overloads, everything else being equal.
> So, in order to give the maintainers more time for review, I'd like to ask
> a feature freeze extension for QStringView until end of next week, plus a
> days to deal with maintainer review comments.
> Why should it be granted? Because QStringView is by far the biggest
> in Qt since 5.0, all the while integrating naturally and step-by-step into
> existing code, _tremendously_ simplifying it along the way (cf. the commits
> that start to make use of QStringView: https://codereview.qt-
> project.org/183864 https://codereview.qt-project.org/183925), esp. where,
> private API, we can already remove the other overloads.
> Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt, C++ and OpenGL Experts
> Development mailing list
> Development at qt-project.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development