Using a const QString & if a function returns a QString

[l3u_]

Hi :-)

Maybe this is a dumb question (maybe caused by lack of C++ knowledge), but I'm not sure if I have faulty reasoning about this:

When calling a function using e. g. a QString, it seems to be reasonable to me to use (if possible) a const QString & to call it so that no copy of the QString is passed to the function, but only a reference to the actual data. But what about a function returning a QString?

I have e. g. the following code:

const QString text = jsonObject.value(someKey).toString();
someFunction(text);
someOtherFunction(text);

The following works as well:

const QString &text = jsonObject.value(someKey).toString();
someFunction(text);
someOtherFunction(text);

QJsonValue::toString() returns a QString. So what is referenced in the second case? The return value of the function as long as it doesn't go out of scope? And is it better to do it in this way?

Thanks for all clarification!

[aha_1980]

Hi @l3u_

what you found is Reference Lifetime Extension - so you referenced a QString.

However, as the Qt data classes implement implicit sharing, the first variant is the one you will see more often (and that is used within Qt itself also).

Regards

[l3u_]

So … should I use const QString text = or const QString &text = ? Are there any (dis)advantages of one version?

[JonB]

@l3u_
QStrings already do not work by copying as you assumed, e.g. from docs

Behind the scenes, QString uses implicit sharing (copy-on-write) to reduce memory usage and to avoid the needless copying of data.

[mrjj]

Hi
so basically you can use const QString text and get sort of const QString &text effect.
This is as mentioned handled by the QString class and makes copying QStrings cheap as they
share the string data unless one of them modifies it. TL:DR version.. ;)
const is always good to use for +1 for that.

[l3u_]

Thanks for the clarification :-)

[bam80]

So … should I use const QString text = or const QString &text = ?

@l3u_ In my understanding, there is still difference:
while with implicit sharing copying is cheap, it still implies reference counting, at least until RVO(Return Value Optimization) is not taken in account.
With const references, we can avoid that unconditionally.

I'm not sure if there are some conventions about it, though.

[Christian Ehrlicher]

@bam80 said in Using a const QString & if a function returns a QString:

With const references, we can avoid that unconditionally.

Correct, but in the current case of jsonObject.value(someKey).toString(); it does not matter since it returns a QString, not a const QString reference.

[bam80]

@aha_1980 said in Using a const QString & if a function returns a QString:

However, as the Qt data classes implement implicit sharing, the first variant is the one you will see more often

BTW, I'm not sure why we are speaking about implicit sharing here - there is no copying occurs anywhere in the original code I suppose (assuming the functions take it's arguments by reference), isn't it?

[Christian Ehrlicher]

@bam80 said in Using a const QString & if a function returns a QString:

there is no copying occurs anywhere in the original code

it is:

const QString text = jsonObject.value(someKey).toString();

At least with c++11 or c++14. See https://en.cppreference.com/w/cpp/language/copy_elision