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

Thiago Macieira thiago.macieira at intel.com
Fri Feb 21 21:49:08 CET 2014


Em sex 21 fev 2014, às 16:49:39, Oswald Buddenhagen escreveu:
> ah, you are thinking qt 6 here.

Yes. I'd rather do the deprecation as soon as possible so we can have a 
smoother transition when we come to it.

> > 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).

Indeed. And since QByteArrays will be cheap for constant data, one of the 
changes should be to remove the QByteArrayLiteral stuff that moc is carrying. 
For Qt 6, we can go back to a plain string table and only record the length.

That's another of the patches that I've been carrying for 2½ years.

But to do what you're asking, we have to revisit the problem of the 
terminating null. Any sub-string (except right()) will not have terminating 
nulls. That might become a big problem.

The other thing I'll need to investigate is the null-vs-empty distinction. 
Right now, they're distinct because we have a special value for the d pointer 
for a null object. If I remove the "is static" check on the refcount, I'll 
need to store the distinction somewhere. Options I can think of:

1) keep a non-null d for an empty-but-not null object (size == 0)
  a) d points to a read-write section of memory where we can ref up and down
	drawback: slowness due to atomic operations in multiple cores

  b) d points to another special value, like d = 0x1
	bool isStatic() const { return (quintptr(d) & ~1) == 0; }
	/// Returns false if deallocation is necessary
	bool deref() { return isStatic() || d->deref(); }

2) keep a null d for static empty, but a non null begin pointer
	bool isNull() const { return d == nullptr && b == nullptr; }
	bool isEmpty() const { return size == 0; }
	T *constData() const { return b; }

drawback: constData() would return nullptr for a null object, which would 
allow people to start relying on that.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center




More information about the Development mailing list