[Development] RFC: Deprecating setSharable / isSharable in our containers and QString

Oswald Buddenhagen oswald.buddenhagen at digia.com
Fri Feb 21 16:49:39 CET 2014


On Thu, Feb 20, 2014 at 12:07:44PM -0800, Thiago Macieira wrote:
> 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.
> 
ah, you are thinking qt 6 here.

> 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.
>
another advantage of that model is that shared substrings would be
rather cheap, which means that my fromRawData() magic could be dropped,
and the existence of QStringRef could be re-evaluated (there is still
the refcount, but that may be insignificant in the bigger picture on
modern hardware).

> The third step will be to investigate whether Small String Optimisation makes 
> sense.
>
my guess is that it is not worth the effort.
in most cases where you are dealing with non-constant short strings you
are dealing with substrings with a very limited lifetime, which would be
well covered by the previous point.
and you have all the branches to deal with the "denormalized" strings
which make read-only operations slower.
anyway, have fun finding out. ;)



More information about the Development mailing list