[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