QString::number returns NaN, but only after compilation
-
@Christian-Ehrlicher Right, I guess what im saying is that any arbirtrary arrangement of bits that as up to four bytes should be a valid number of some kind, right?
@drew_hamilton said in QString::number returns NaN, but only after compilation:
I guess what im saying is that any arbirtrary arrangement of bits that as up to four bytes should be a valid number of some kind, right?
No, float is a IEEE-754 floating point number.
And now please go to all places where you modify this value and check them. Esp. if you e.g. divide by 0 for accident or similar.
-
You get that number from "Somewhere", right ? Maybe an external device or library ?
If it doesn't work when executed outside of the IDE, then I would suspect some kind of race condition or hiccup when communicating with the device in that the timing has changed. In which case you are getting garbage bits that don't conform to a floating point number. -
I found a variable feeding this number that was not initialized with a value and this got rid of the issue. Still really scratching my head as to why it's not initialized in different contexts.
-
I found a variable feeding this number that was not initialized with a value and this got rid of the issue. Still really scratching my head as to why it's not initialized in different contexts.
@drew_hamilton said in QString::number returns NaN, but only after compilation:
I found a variable feeding this number that was not initialized with a value and this got rid of the issue.
There you are, as we ( @Christian-Ehrlicher) suggested!! Aren't you pleased you have tracked a nasty bug down?!
(BTW, do you have all compiler warnings on? You ought to. These days compilers are pretty good at telling you when they see a potentially-uninitialized variable used, but depends on your usage in code.)
Still really scratching my head as to why it's not initialized in different contexts.
It is never "initialized" in any context, since you have said it's "not initialized with a value" by your code. In that case, say it's on the stack (e.g. local variable), its value will be whatever happens to be in that memory location at the time. And, simply put, that can vary across builds, build-types, environments run from, time of day, or weather. You were "lucky" it ever worked OK, you may never find a pattern which tells you what its value was or why it varied.
