OK, sorry for long reply, didn't get subscript notif. Sorry you guys didn't understand, let me try to explain better:
Let's take a look at the outside (not in 'if' statement) calls:
c=0000000000455818
full=0000000000455818
c=000000000045581A
full=000000000045581A
c=000000000045581C
full=000000000045581C
c=0000000000455818
full=0000000000455818
c=000000000045581A
full=000000000045581A
c=000000000045581C
full=000000000045581C
To copy to clipboard, switch view to plain text mode
So No, every time "toPlainText()" is called it's not returning a new object. It's returning the same memory (base at 0x455818). The addresses under "full" are 16 bit sequential and toPlainText() is called each time.. (818, 81A, 81C). This is fine. Rather expected behavior. I know you're not guaranteed that the object is the same each time - but it is here for each iteration.
I'm concerned about the difference in behavior outside and inside.
Obviously 'c' is pointing to same address as "results_box->toPlainText()" each call (which implies it's the same object returned each time), but inside (and only inside) the 'if' statement when I call: "results_box->toPlainText().constData()" it returns a new address (ok, fine, let's say that's expected because it returned a new object) but then AFTER (the next iteration) outside the 'if' they point to the same addr again. This behavior of matching and not matching is very confusing to me.
So basically what happens is as follows:
Iteration 0:
Outside 'if': 'c' and full call point to same address (ie. 0x80) (EXPECTED
Inside 'if': 'c' points to 0x80, full call points to 0x880 (MAYBE EXPECTED (if each call yields new object))
Iteration 1:
Outside 'if': 'c' and full call point to same address again (0x82) (NOT expected if we take assumption that full call returns new object)
Inside 'if': 'c' points to 0x82 (EXPECTED) but full call points to arbitrary address ('c' no longer valid)
Iteration 2:
Outside 'if': 'c' and full call point to same address (NOT expected, especially since 'c' was just invalid at end of iteration 1)
...
Iteration 0:
Outside 'if': 'c' and full call point to same address (ie. 0x80) (EXPECTED
Inside 'if': 'c' points to 0x80, full call points to 0x880 (MAYBE EXPECTED (if each call yields new object))
Iteration 1:
Outside 'if': 'c' and full call point to same address again (0x82) (NOT expected if we take assumption that full call returns new object)
Inside 'if': 'c' points to 0x82 (EXPECTED) but full call points to arbitrary address ('c' no longer valid)
Iteration 2:
Outside 'if': 'c' and full call point to same address (NOT expected, especially since 'c' was just invalid at end of iteration 1)
...
To copy to clipboard, switch view to plain text mode
So basically I'm concerned with the difference in behavior between inside and outside the 'if'. You guys are saying that it's returning a new object each time. If that's the case then it's strange that outside the 'if' statement it literally returns the same exact base address for each of the many iterations. OUTSIDE the 'if' the print doesn't reflect what you're saying, but INSIDE the 'if' statement it does. I don't get how that's possible.
Synopsis:
You're likely saying "why do you care?" My code (how I stumbled on this issue) was originally as follows:
const QChar *c
= results_box
->toPlainText
().
constData();
for (int i = 0 ; i < results_box->toPlainText().size() ; ++i)
{
if (0)
{
//never goes in here, I forgot what it was originally..
}
else
{
std::cout << "Saved call:" << &(c[i]) << " : " << c[i].toLatin1() << std::endl; //!!!! c[i] returns ASCII 0 for all values, completely unexpected to me - I just wanted a pointer to the char data inside the field.
}
}
const QChar *c = results_box->toPlainText().constData();
for (int i = 0 ; i < results_box->toPlainText().size() ; ++i)
{
if (0)
{
//never goes in here, I forgot what it was originally..
}
else
{
std::cout << "Saved call:" << &(c[i]) << " : " << c[i].toLatin1() << std::endl; //!!!! c[i] returns ASCII 0 for all values, completely unexpected to me - I just wanted a pointer to the char data inside the field.
}
}
To copy to clipboard, switch view to plain text mode
I was originally thinking as you guys are saying that each call will return a new QString object each time and the QString is no longer valid but when I printed the addresses outside the 'if' statement in the for loop it all shows the same object at the original base
Hope that elaborates what I originally tried (and what went wrong) and how I got lead into this interesting scenario.
Bookmarks