can not print correctly after convert QString to char *

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).

Christian Ehrlicher

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

where is the temp object in memory, stack or heap or somewhere else.

It's on the stack since you did not allocate it with new

if it is on stack, it can not remain until the stack is finished

No, this is not allowed since it's unnamed.

It's also not c++ specific - you can do the same (in a little bit more obvious way) in C:

int *myPtr = nullptr;
{
  int a = 3;
  myPtr = &a;
  printf("%d\n", *myPtr);   // works fine
}
printf("%d\n", *myPtr);   // works on garbage and may eat kitten

JonB

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

int *myPtr = nullptr;

Never heard of nullptr in C ;-) NULL was much nicer to read anyway.

jsulm

This post is deleted!

Mozzie

@Christian-Ehrlicher
thanks, it helped a lot.
and i have a hunch

{//main stack
	QString s = "hello world";
	char* p = nullptr;
	{// toUtf8()
		QByteArray b = s.toUtf8();
		{// data();
			p = b.data();
			qDebug() << p; // does this is same as "qDebug() << s.toUtf8().data();"
		}
	}
	// b is freed
	qDebug() << p; // this is same as "char * p = s.toUtf8().data(); qDebug() << p;"
}

does this right?

Mozzie

@JonB
nullptr is a c++11 key word, you can still use NULL, but NULL is defined as 0, sometimes it may cause some problem.

such as:


void test(int *p)
{
	qDebug() << "int *";
}
void test(int i)
{
	qDebug() << "int";
}
test(NULL);
test(nullptr);

output

int
int *

JonB

@Mozzie
I know this :) That's why I was picking @Christian-Ehrlicher on his use of nullptr in his C program, it was just intended for amusement ;-)