Il 27/03/2017 17:46, Thiago Macieira ha scritto: >> Another point that hasn’t been discussed yet, is how to handle QStringRef. >> In my opinion, we should deprecate it, but it’s used quite a bit in some >> parts of our API (QXmlStreamReader comes to my mind). It would be good to >> also think about how to solve that case. QStringRef has a pointer to a >> QString, but does not increase the refcount of it. So it looks like we can >> simply make it an alias for QStringView. That would break the >> QStringRef::string() method (which we should probably deprecate in 5.10 to >> prepare for the change), but everything else should stay compatible. > We can't... I tried that a while ago and it broke QXmlStreamReader and other > places badly. The issue is that they expect QStringRef to continue to be > valid > after mutating the QString it was bound to. That works because of the pointer > to the QString, as opposed to a pointer to the data. And that's just what I > found by after changing QStringRef a few years ago to be like QStringView > today and simply running Qt Creator. > > We can port away from QStringRef and into QStringView as we go by and where > it's safe. But unless we're willing to refactor some code substantially. > Unfortunately, it's very likely we can't begin this work now as it would > break > the QStringRef API and thus be BIC/SIC.
If we can't make it an alias, can we start adding extra functions for the various QStringRef *ref() methods (in QXmlStreamReader, QRegularExpressionMatch, probably elsewhere too), returning QStringView? Cheers, -- Giuseppe D'Angelo | [email protected] | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
