Solved can not print correctly after convert QString to char *
-
@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? -
@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
-
@VRonin
Fine. So I carefully read https://doc.qt.io/qt-5/qstring.html#toUtf8Returns 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? -
Hi @JonB,
as @Christian-Ehrlicher said, that is C++ basics: https://en.cppreference.com/w/cpp/language/lifetime
Regards
-
@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?
-
@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.
-
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.... :(
-
Hi @JonB,
if I take your example and do the following:
QByteArray ba = func()
; thenba
lives until it goes out of scope. But if I doQByteArray hex = func().toHex()
I have two conversations in one line. That is no problem here, as I take the result offunc()
and immediately calltoHex()
on it. But note that afterward neither the returned value offunc()
nor oftoHex()
exists anymore, onlyhex
.And that is the whole problem, with
data()
you access the raw data of an object that's lifetime is already over.Regards
-
@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 :-)
-
@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
-
@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 sharedQByteArray
s and stuff.So to summarize:
s.toUtf8()
only "lasts" for the lifetime of the statement (probably rather expression) it is in. But if you goQByteArray b = s.toUtf8()
then theb
will persist OK as usual. Right? -
@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.
-
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 :-)
-
@hskoglund
that is interesting .
i dont have test on linux or MinGW, maybe vs and MinGW is diffrent on deal with temp object? -
@Mozzie Actually MinGW works on Windows as well (I prefer it over MSVC2017 because MinGW compiles/builds my projects faster).
-
@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
-
@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. -
This post is deleted! -
@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?
-
@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 *