can not print correctly after convert QString to char *

Mozzie

Env: vs2017 , Qt 5.14.0, Qt 5.12.6
code:

		QString s = "hello world";
		qDebug() << s;
		qDebug() << s.toUtf8().data();

		char* p = s.toUtf8().data();
		qDebug() << p;

		QByteArray b = s.toUtf8();
		p = b.data();
		qDebug() << p;

output:

"hello world"
hello world
????????????????????????????????????????????7
hello world

can somebody explain this, I'd be appreciate

Christian Ehrlicher

@Mozzie said in can not print correctly after convert QString to char *:

char* p = s.toUtf8().data();

C++ basics - you're creating a temporary here so p points to garbage after this statement.

Rondog

The one version I think you have a problem with is this:

char* p = s.toUtf8().data();
qDebug() << p;

There is a temporary object created and 'p' is a pointer to something that no longer exists when you try to output it on the next line.

JonB

@Mozzie
For your

		char* p = s.toUtf8().data();
		qDebug() << p;

????????

case. https://doc.qt.io/qt-5/qbytearray.html#data

Returns a pointer to the data stored in the byte array.
The pointer remains valid as long as the byte array isn't reallocated or destroyed.

I think it is, between the two lines. That s.toUtf8() looks temporary-ish to me. Use it on one ;line, or give it permanent variable QByteArray b = s.toUtf8(); like you do afterwards, and I think you remove its temporary-ness.

Note

For read-only access, constData() is faster because it never causes a deep copy to occur.

I don't know, but try:

const char* p = s.toUtf8().data();

Any difference in output?

Christian Ehrlicher

@JonB said in can not print correctly after convert QString to char *:

Any difference in output?

For sure not.

JonB

@Christian-Ehrlicher said in can not print correctly after convert QString to char *:

C++ basics - you're creating a temporary here so p points to garbage after this statement.

OK then, let's pick you up on the exactitiudes of this. https://doc.qt.io/qt-5/qbytearray.html#data states:

The pointer remains valid as long as the byte array isn't reallocated or destroyed.

Are you saying the s.toUtf8() is returning a temporary, or going .data() is a temporary?

VRonin

@JonB said in can not print correctly after convert QString to char *:

Are you saying the s.toUtf8() is returning a temporary, or going .data() is a temporary?

The former

JonB

@VRonin
Fine. So I carefully read https://doc.qt.io/qt-5/qstring.html#toUtf8

Returns a UTF-8 representation of the string as a QByteArray.

@Christian-Ehrlicher says the question/code is "C++ basics". I do not see the word "temporary" there. In fact I search the whole of QString doc page and don't find it. So how do I know this, please?

aha_1980

Hi @JonB,

as @Christian-Ehrlicher said, that is C++ basics: https://en.cppreference.com/w/cpp/language/lifetime

Regards

JonB

@aha_1980
Wow, OK, yes, I need to read! My problem is I have been "spoiled" by using C# and then Python/PyQt/PySide2 for so long now that I rarely have to think about this!

So let's take a basic, if my C++ holds up. If I write a function

QByteArray func()
{
    QByteArray qb;
    return qb;
}

does that return such a "temporary object"? And that would be true for any class/struct I decalred and then returned in that fashion?

Christian Ehrlicher

@JonB said in can not print correctly after convert QString to char *:

does that return such a "temporary object"?

It's not about returning something. It's about the lifetime of an object.

JonB

@Christian-Ehrlicher

Temporary objects are created when a prvalue is materialized so that it can be used as a glvalue, which occurs (since C++17) in the following situations:

Lovely!

I also note its second item is:

returning a prvalue from a function

Is that where we are here? I'm not stupid, but I am clearly struggling to recognise which situations this applies in.... :(

aha_1980

Hi @JonB,

if I take your example and do the following: QByteArray ba = func(); then ba lives until it goes out of scope. But if I do QByteArray hex = func().toHex() I have two conversations in one line. That is no problem here, as I take the result of func() and immediately call toHex() on it. But note that afterward neither the returned value of func() nor of toHex() exists anymore, only hex.

And that is the whole problem, with data() you access the raw data of an object that's lifetime is already over.

Regards

hskoglund

@Mozzie You had a bit of bad luck, if you compile in Release mode instead of Debug it'll work fine

"hello world"
hello world
hello world
hello world

And if you switch to MinGW compiler it'll work both in Debug and Release :-)

Mozzie

@Christian-Ehrlicher
Thank you very much, and thank other replyer.
I think i understand your reply, and I do fogot the temp object , maybe because I also use java a lot.

and i alse have a few questions:

where is the temp object in memory, stack or heap or somewhere else.
if it is on stack, it can not remain until the stack is finished

JonB

@hskoglund
Your findings are even more scary in view of the above conversation! :)

@aha_1980 , and others
I think I get it. Also that it's nothing to do with Qt specific classes. Not because of shared QByteArrays and stuff.

So to summarize: s.toUtf8() only "lasts" for the lifetime of the statement (probably rather expression) it is in. But if you go QByteArray b = s.toUtf8() then the b will persist OK as usual. Right?

aha_1980

@hskoglund said in can not print correctly after convert QString to char *:

And if you switch to MinGW compiler it'll work both in Debug and Release :-)

Today. Tomorrow it will run away with your wife, bankrupt your workplace and aim for world domination.

hskoglund

Yes! I's just luck that the bits are still around in Release mode. The Debug mode output of ??????? could happen in Release also some other day when the sun doesn't shin.e

Anyway, one simple modification to make it waterproof could be:

QString s = "hello world";
qDebug() << s;
qDebug() << s.toUtf8().data();

QByteArray a = s.toUtf8();
char* p = a.data();
qDebug() << p;

QByteArray b = s.toUtf8();
p = b.data();
qDebug() << p;

Edit: too fast, didn't read the code in the 3d paragraph ! But they are both waterproof now :-)

Mozzie

@hskoglund
that is interesting .
i dont have test on linux or MinGW, maybe vs and MinGW is diffrent on deal with temp object?

hskoglund

@Mozzie Actually MinGW works on Windows as well (I prefer it over MSVC2017 because MinGW compiles/builds my projects faster).