QString::number returns NaN, but only after compilation
-
@drew_hamilton said in QString::number returns NaN, but only after compilation:
How could a variable be uninitialized when run from File Explorer and initialized when run from the command prompt?
You said in debug mode it's fine so it can be that the memory the variable points to is initialized to a usable value, in release mode it's not. So it's a common uninitialized variable problem.
@Christian-Ehrlicher
While it does sound like an uninitialized, the OP actually wrote earlier:If I run this code in the QT IDE in either Release or Debug, the values show as numbers. If I run a standalone EXE that I have compiled, it shows as NaN.
I think he's saying any version works from IDE, no version outside.
I guess random memory contents could differ when run in those two cases. Otherwise maybe the environment is different for whatever measurements they do to collect the figures.
@drew_hamilton
If it is an uninitialized variable really you have to track it down. -
@Christian-Ehrlicher
While it does sound like an uninitialized, the OP actually wrote earlier:If I run this code in the QT IDE in either Release or Debug, the values show as numbers. If I run a standalone EXE that I have compiled, it shows as NaN.
I think he's saying any version works from IDE, no version outside.
I guess random memory contents could differ when run in those two cases. Otherwise maybe the environment is different for whatever measurements they do to collect the figures.
@drew_hamilton
If it is an uninitialized variable really you have to track it down.@JonB Correct.
@Christian-Ehrlicher The variable is initialized as 666, just to make sure it has SOME value to begin with. It is initialized in public section of my MainWindow class. This doesn't seem to be enough (when running as a standalone executable from File Explorer). If I overwrite the value directly before generating my QString, it will of course use that value. This means that somehow this variable is not initialized by my class, but only in the context of running the executable from File Explorer. It is initialized when run from the IDE and when run from the Command Prompt as a standalone executable.
Surely you can understand why I am scratching my head.
The initialization happens something like this:
class MainWindow : public QMainWindow
{
Q_OBJECTpublic:
MainWindow(QWidget *parent = nullptr);
~MainWindow();void setup_layout_for_serialComs();... blah blah...
float RX_freq_hz = 666; float TX_freq_hz = 666; -
@JonB Correct.
@Christian-Ehrlicher The variable is initialized as 666, just to make sure it has SOME value to begin with. It is initialized in public section of my MainWindow class. This doesn't seem to be enough (when running as a standalone executable from File Explorer). If I overwrite the value directly before generating my QString, it will of course use that value. This means that somehow this variable is not initialized by my class, but only in the context of running the executable from File Explorer. It is initialized when run from the IDE and when run from the Command Prompt as a standalone executable.
Surely you can understand why I am scratching my head.
The initialization happens something like this:
class MainWindow : public QMainWindow
{
Q_OBJECTpublic:
MainWindow(QWidget *parent = nullptr);
~MainWindow();void setup_layout_for_serialComs();... blah blah...
float RX_freq_hz = 666; float TX_freq_hz = 666;@drew_hamilton
But the question is what happens to thisRX_freq_hzfrom now on. We assume it's updated all the time? If that calculation make it becomenanbecause of some issue elsewhere. I assume if you left it at666and never updated it it would never show asnan!?Use bool qIsNaN(double d) immediately before you go
QString::number(RX_freq_hz), or whatever you display. I assume that returns true whennanis displayed. Then it's not aQString::number()issue, it's the value for sure. Wherever that comes from. -
@JonB Correct.
@Christian-Ehrlicher The variable is initialized as 666, just to make sure it has SOME value to begin with. It is initialized in public section of my MainWindow class. This doesn't seem to be enough (when running as a standalone executable from File Explorer). If I overwrite the value directly before generating my QString, it will of course use that value. This means that somehow this variable is not initialized by my class, but only in the context of running the executable from File Explorer. It is initialized when run from the IDE and when run from the Command Prompt as a standalone executable.
Surely you can understand why I am scratching my head.
The initialization happens something like this:
class MainWindow : public QMainWindow
{
Q_OBJECTpublic:
MainWindow(QWidget *parent = nullptr);
~MainWindow();void setup_layout_for_serialComs();... blah blah...
float RX_freq_hz = 666; float TX_freq_hz = 666;@drew_hamilton said in QString::number returns NaN, but only after compilation:
It is initialized in public section of my MainWindow class.
But you modify it somewhere and access an uninitialized value there.
-
@drew_hamilton said in QString::number returns NaN, but only after compilation:
It is initialized in public section of my MainWindow class.
But you modify it somewhere and access an uninitialized value there.
@Christian-Ehrlicher I'm wondering how it would be possible to put a NaN value into a float as it is just 4 bytes. Assuming the variable EXISTS, anything you put into it should be between -32767 and 32767. Maybe I misunderstand something about how that works.
-
@Christian-Ehrlicher I'm wondering how it would be possible to put a NaN value into a float as it is just 4 bytes. Assuming the variable EXISTS, anything you put into it should be between -32767 and 32767. Maybe I misunderstand something about how that works.
@drew_hamilton said in QString::number returns NaN, but only after compilation:
NaN value into a float as it is just 4 bytes. Assuming the variable EXISTS, anything you put into it should be between -32767 and 32767.
Ok, now please go back to the basics... float is not an integral number...
-
@drew_hamilton said in QString::number returns NaN, but only after compilation:
NaN value into a float as it is just 4 bytes. Assuming the variable EXISTS, anything you put into it should be between -32767 and 32767.
Ok, now please go back to the basics... float is not an integral number...
@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?
-
@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.
