[Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Matthew Woehlke]

On 2015-10-14 06:16, Marc Mutz wrote:
> First, afaiu from what Thiago mentions in reviews, Q6String will have SSO 
> (small-string-optimisation) which makes many short strings expensive to copy 
> (if you think that copying 24 bytes is slower than upping an atomic int 
> through an indirection) or cheap to copy (if you think the opposite). In any 
> case, small strings will be very cheap to create (no allocation), so for many 
> strings there will be not much difference between passing a QStringView or 
> passing a QString.

Atomic operations are expensive (I think I heard once 'on the order of
100 instruction cycles', but that's highly apocryphal), mainly I would
guess due to the need to maintain cache coherency. A small copy might
happen entirely in local hot cache. 24 bytes is a whole three registers
on a modern 64-bit machine. That's probably not going to be very slow.

(Mind, atomics still blow full mutexes out of the water, but they're
still an order of magnitude slower than small stack allocations and most
single machine instructions.)

>> Yes, signed please. We can discuss whether it should be 64bit for Qt 6.
> 
> The current std API uses size_t. Do you (= both of you) expect that ever to 
> change? If it doesn't, Qt will forever be the odd one out, until we finally 
> drop QVector etc for std::vector etc and then porting will be a horror because 
> of MSVC's annoying warnings.

STL should change. In Qt and Python, you can use negative indices to
refer to a distance (length) relative to the end (length) of the string.
In STL you can't do that, which is a significant limitation by
comparison. Please don't drop this useful functionality!

> array_view cannot compete with QByteArray's API. E.g. there's no toInt().

...and it *shouldn't*. Never mind that you're talking about a function
that deals with *strings*, it's debatable whether that sort of thing
belongs as class methods at all. Anyway, they aren't "missing" in the
standard library; they're free functions.

(That said, the CSL could use better flavors, and there was some talk of
that, but AFAIK it didn't get anywhere. I can pretty well guarantee you
the committee isn't going to be adding that sort of thing to array_view,
or even string_view, any time soon.)

-- 
Matthew