Qt::StringLiterals

[Redman]

using namespace Qt::StringLiterals;

//1
qInfo() << u"Hello"_s;

//2
QString name = "Tim";
qInfo() << u"Hello %1"_s.arg(name);

1:
Equal to QStringLiteral

2:
What happens here?
Is this some kind of hybrid where Hello %1 is compiled but during runtime a new QString is created anyway because of the argument?
Is this even benefitial?

[kkoehne]

But there is a 50% performance increase anyway right?

The exact overhead is not that easy to guess, as some other things come into play. First, even for u""_s, there is some constant overhead for constructing a QString object. And second, there is also other overhead, like looking up %1 ...

But u""_g should always be faster than using just QString(const char*), as the latter needs to a) calculate the length of const char * by looking for the final NULL character, and b) convert UTF-8 to UTF-16. Mind you, these are very optimized operations, so the savings in a typical app aren't typically dramatic. But if you can avoid even some overhead by just using convenient API, why wouldn't you?

[kkoehne]

Is this some kind of hybrid where Hello %1 is compiled but during runtime a new QString is created anyway
because of the argument?

Exactly.

u"Hello %1"_s will create a QString with "Hello %1" as content at compile time. At runtime, QString::arg() is then called, which will generate a new QString "Hello Tim".

Is this even benefitial?

In this snippet, no. You might as well just write u"Hello Tim"_s. You typically use arg() if the arguments are not determined at compile time.

[Redman]

@kkoehne
But there is a 50% performance increase anyway right?

Taking the precompiled string and creating a new QString as a result of .arg() is more efficient that
creating QString("Hello %1") and then creating another one with arg(). In the docs it says that arg returns a new QString, which makes the QString("Hello %1") approach 2x as expensive as the first.

The Tim example is a simplification of a string that is not know during compile time.

[kkoehne]

But there is a 50% performance increase anyway right?

The exact overhead is not that easy to guess, as some other things come into play. First, even for u""_s, there is some constant overhead for constructing a QString object. And second, there is also other overhead, like looking up %1 ...

But u""_g should always be faster than using just QString(const char*), as the latter needs to a) calculate the length of const char * by looking for the final NULL character, and b) convert UTF-8 to UTF-16. Mind you, these are very optimized operations, so the savings in a typical app aren't typically dramatic. But if you can avoid even some overhead by just using convenient API, why wouldn't you?