> On 28 Mar 2017, at 07:01, Thiago Macieira <[email protected]> wrote: > > On segunda-feira, 27 de março de 2017 14:53:05 PDT Giuseppe D'Angelo wrote: >> Why should it bad if what you want return is precisely a "const >> reference" over QString-like data? Isn't that the whole reason why we >> have functions returning QStringRef right now (lacking a QStringView)? >> (And also the reason why QStringView itself returns QStringViews?) > > The functions returning QStringRef are not a good practice. They are bad API > in the first place, so please don't make the situation worse.
I agree in general, but there are valid exceptions. Parsers are one of those places where returning a QStringView with a documented lifetime (e.g. until your next call into the parser) is IMO a valid thing to do (since performance is critical here). > > Now, replacing QStringRef with QStringView may be acceptable, as it makes the > problem not much worse. But at least in the case of QXmlStreamReader, it > does, > so that won't work. I guess that’s because of some issues in how the XmlStreamReader allocates (or re-allocates) it’s string. We should probably simply try to see how we can fix the implementation instead of saying that we can’t change the API to use QStringView. > >> Example of use case: a tokenizer operating over QString-like data, >> returning each token as a QStringView, with no memory allocations -- >> possibly even noexcept (narrow contract on the source string). Why would >> I want to return QStrings for this use case and super-pessimize it? > > Tht's probably acceptable. We need to study each case in a case-by-case basis. > > Rule of thumb is to return QString. By default, return values should be QString, I agree. Returning QStringView exposes more internals of the class. It does make sense in certain use cases though. Cheers, Lars _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
