Kurt, The mail you're replying to has nothing to do with QStringView. It was a tangent about std::string_view.
If you need a real-world example of where QStringView would be handy: Some 3rd-party code returns you a char16_t *path, and you want to perform a QDir::cd(). Currently, you need to create a QString (which allocates). Had QDir::cd() taken a QStringView, you wouldn't have that allocation. Another example I already mentioned: > E.g. local QStrings could be replaced by QVarLengthArray<QChar>, > > e.g. in code like this: > QString joinstr = QLatin1String("\"\n"); > joinstr += indent; > joinstr += indent; > joinstr += QLatin1Char('"'); > > QString rc(QLatin1Char('"')); > rc += result.join(joinstr); > rc += QLatin1Char('"'); > > Even when replaced with QStringBuilder: > QString joinstr = QLatin1String("\"\n") + indent + indent > > + QLatin1Char('"'); > > QString rc = QLatin1Char('"') + result.join(joinstr) + > QLatin1Char('"'); > > But the main benefit would be that we only ever need one overload for a > QString-taking function, not N, N > 3. Final with QStringView (and a minor modification to QStringBuilder): QVarLengthArray<QChar> joinstr // doesn't alloc (for most 'indent's) = QLatin1String("\"\n") + indent + indent + QLatin1Char('"'); // in this line, QStringList::join() doesn't know about QVarLengthArray. // but it takes a QStringView and therefore transparently accepts QVLA QString rc = QLatin1Char('"') + result.join(joinstr) + QLatin1Char('"'); Please understand my POV: I am of the firm belief that Qt has no business creating inefficiencies for its users by sloppy implementation. Anywhere. We cannot know whether one user is calling QString::multiArg() in a tight loop. It might be dominating her runtime. 99.9% of users probably couldn't care less about QString::multiArg() performance. But we need to care about the 0.1%, because that number is much closer to 100% if you integrate it over all users' critical paths (iow: every Qt user will have *some* part of Qt that she wished was faster, heck, iirc KMail ran into QObject::connect as a bottleneck at some point in the past!). The inefficiencies I (and Sergio and Milian and, I'm happy to see, Friedemann, and others) care about are not ones you will find in a profiler in those 99.9% of cases, because they are not used in a critical path. But even for the 99.9% of users, if we make all of Qt 10% faster on average, their apps will run close to 10% faster, too. Automatically. So yes, I care about performance. I find it intolerable that todays software takes 1000x the memory, 1000x the CPU capacity and doesn't get a given jobs done in less wallclock time than software 20 years ago. And people don't use C++ because it's pretty. You cannot compete with Java on programmer efficiency. Its standard library is orders of magnitude larger than C++'s. People choose C++ (and accept the associated loss in programmer efficiency), because they require the bare metal efficiency of C++. And if Qt gets in the way, they will look for alternatives and find them in places that make Qt look like paradise. That said, QStringView is as much about - slim interface type vs. thick, fat, storage type - interop with 3rd-party and native code than it is about efficiency. Bottomline: I don't need a fancy anylysis to tell me that less allocations = faster programs = more happy Qt users. And please don't forget that QString fanboys can continue to massacre the heap if they so wish. After all, we've had QStringRef for a long time now, but most people still write str.mid(n).toInt() instead of str.midRef().toInt(). QStringView won't change that: A function taking QStringView accepts a QString, too (either by implicit conversion, or where it makes sence, by QString overload). Thanks, Marc On Friday 16 October 2015 21:42:23 Kurt Pattyn wrote: > Marc, > > It is clear that your main concern is performance (needless conversions) > and convenience (being able to work efficiently with 3rd party libraries). > Regarding performance, I think it would be good if we could come up with > some numbers. How 'bad' is the current implementation compared to an > 'ideal' situation? And then define some acceptable target keeping into > account convenience. Otherwise I am afraid that discussions can keep going > forever over 1 instruction more or less. Regarding convenience, and that > is what Qt is all about, I think you made a tremendous proposal that can > really bring Qt a big step forward. The idea is very sound and clear. Of > course, there are technical challenges, but that is what we are supposed > to solve. > > I also agree that we should aim for simplicity. QString and QStringView is > simple to understand, iff we can get rid of all other string related > classes. The ideal case would be just to have one QString class, although > I doubt that is achievable. > > I think it would be good to come up with some real-world use-cases that > show how a Qt user and a Qt application could benefit from your proposal. > Personally, I never experienced a performance problem with QString; but > then the applications I write are not very string oriented. I am a QString > aficionado :-) > > After all, what I really like about Qt is convenience, simplicity and > portability. I think this should be the main focus of Qt, and that also > implies smooth collaboration with the outside world. > > Cheers, > > Kurt > > > On 16 Oct 2015, at 21:47, Marc Mutz <marc.m...@kdab.com> wrote: > >> On Friday 16 October 2015 19:31:50 Thiago Macieira wrote: > >> The conversion from one to the other is one instruction. > > > > Which is one instruction too much for tail-call optimisation, e.g. > > > > But the point was about std::string_view binary compatibility. As > > basically a C struct with no ownership semantics, it would be a perfect > > vehicle to pass strings around different programming languages and > > compilers, but only if the ABI (ie. the data members) were specified. -- Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development