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

[Thiago Macieira]

On Wednesday 14 October 2015 09:59:28 Matthew Woehlke wrote:
> 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.

This discussion is a red herring. It's not a choice between copying and 
atomically incrementing a reference counter. It's a choice between copying and 
between copying plus incrementing the reference counter.

	QString s2 = s1;

needs to copy those bytes that are sizeof(QString) *anyway*, regardless of 
whether in addition to that it will increment the refcount.

> >> 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!

And see discussions in the std-discussions and std-proposals mailing list. I 
repeat what I said: the current *committee* stance is that you should use 
signed for everything, except when you need well-defined overflow behaviour.

The only problem, which I raised there and did not get resolved, is which type 
to use.

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