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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development