Solved can not print correctly after convert QString to char *
-
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
-
@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.
-
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.
-
@Mozzie
For yourchar* 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 variableQByteArray 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?
-
@JonB said in can not print correctly after convert QString to char *:
Any difference in output?
For sure not.
-
@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).