On Wed, Oct 14, 2015 at 11:15:55AM +0000, Knoll Lars wrote: > >That leaves classes which simply store the string. You cited QUrl. I > >don't see > >a problem providing QString overloads for these, esp. considering that > >we're > >starting out with an all-QString API here. Then again, once we have > >QStringView overloads, we can simply disable the QString overloads and > >see the > >effect. > > I think there’s actually quite a few of those. In addition, it might be > tricky to use QStringView in signals and slots.
One could try to be clever and go through an intermediate QString object at least in queued connections. Or even always. > [...] > Of course we don’t know all it’s uses. But many uses outside of QtCore are > clearly less critical. QLineEdit::setText is clearly not called in tight > loops, and once you set the text it has to do lots of other work. There > are many similar APIs in Qt, where I don’t think we’ll ever see a benefit > of a QStringView, and the simplicity of passing in a const QString ref is > probably preferrable. Right. OTOH there are instances where it provably *does* matter, e.g. everything in the vicinity of QFileInfo, or: > >Take QDateTime as a warning. ... > I am certainly in favor of experimenting with this. Let’s start in a > branch or behind an ifdef. Or in a safer place. See my other mail. Andre' _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development