[Development] RFC: Deprecating setSharable / isSharable in our containers and QString
Thiago Macieira
thiago.macieira at intel.com
Thu Feb 20 21:07:44 CET 2014
Em qui 20 fev 2014, às 19:56:42, Oswald Buddenhagen escreveu:
> what are you planning to do?
This is the first step: remove setSharable so we have one fewer state to check
during ref up & down. Keeping isSharedWith is no problem, as it doesn't affect
the refcounting.
The second step will be to use null d-pointers to indicate static data. That
means Q{String,ByteArray}Literal() and
Q{String,ByteArray,Vector}::fromRawData() don't have to have a d-pointer. For
the latter, it has the extra benefit that fromRawData() won't allocate memory
at all.
Obviously, if the d-pointer is null, neither the pointer to the data nor the
size can be inside the d pointer. That means we have to extract the begin and
size from inside the d-pointer and move to the actual class. Fortunately,
that's already implemented and very robust. I implemented it close to 3 years
ago.
https://qt.gitorious.org/qt/thiago-intels-qtbase/commit/8ec07482b2ca9674ee72061c0273e527bc63ad47
https://qt.gitorious.org/qt/thiago-intels-qtbase/commit/3534934f0da0442a75b99fbab0328ce55c26798e
That means
sizeof(QString) == sizeof(QByteArray)== sizeof(QVector) == 3 * sizeof(void*)
I have a corresponding change to grow QVariant to 4 * sizeof(void*) so
QStrings can fit.
The third step will be to investigate whether Small String Optimisation makes
sense. By using the LSB in the d-pointer to indicate whether the SSO is
active, we can store:
32-bit 64-bit
QString 5 chars 11 chars
QByteArray 11 chars 23 chars
(including the ending null)
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Development
mailing list