Great job! 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 <[email protected]>: > Hi, > > 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: > http://lists.qt-project.org/pipermail/development/2015-October/023358.html > > Here's the evolving patch series: > https://codereview.qt- > project.org/#/q/status:open+project:qt/qtbase+topic:qstringview,n,z > > 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 > between > the Qt preference of 32-bit signed types over the STL preference for > 64-bit > 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 > places > 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 > QStringRef > overloads (2: only where the function read from the string, 3: also > where > it stores the string), so that at some later point in time we can just > flip > 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 > for > a feature freeze extension for QStringView until end of next week, plus a > few > days to deal with maintainer review comments. > > Why should it be granted? Because QStringView is by far the biggest > revolution > 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, > in > private API, we can already remove the other overloads. > > Thanks, > Marc > > -- > Marc Mutz <[email protected]> | 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development >
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
