In 64bit code (so using XMM registers) it'll probably work, unless any DLL secretly changes a rounding mode on you and "forgets" to set it back. In 32bit code (usually using the x87 FPU stack), who knows? The danger there as usual is that keeping a double in an FPU register keeps it at whatever value was actually computed (which depending on how stod works internally may have bits set in the part of the 64bit significand that extends beyond the 53 bits you usually get) while storing it to memory and reloading it changes the value, and this is something that compilers think is a normal part of how they work so they do it outside of your control, though you can force a store/reload to get a safer value to work with. So it may still work, but there are some sneaky conditions that may depend on specific codegen choices the compiler makes.
Thank you so much!
To be honest I don't get all of your explanations at the moment. But the most important Thing is, that you Point out, that there can be a Problem... and that corresponds with "my bad Feeling".
So now it will be my part to investigate more for possible pitfalls
Thank you very much again.
And please flag your Response as an answer, it is much more than a "general"
It does not solve my Problem, but it answers my question
This is really too pessimistic about floating point arithmetic though. There are definitely cases where doubles will reliably have exactly equal values. They're not non-deterministic, just hard to work with and 80bit nonsense messes things up extra.
The key point of a map is that no two elements in a map container can have equivalent keys. If the number of significant digits entered is less than the precision of double values, this will not happen (besides entering the same value again which applies to ints as well).
But you might get problems when trying to access elements by key when the argument is from other sources (affected by rounding).
That would be my bad feeling:
While there is no problem with the map itself, key based operations (operator, erase, swap, find) might behave not as expected (no match). Even when not using such operations now but only iterator based ones, they may be used later when updating the code. So you should at least place a comment about this.
Another option is creating your own std::map based class that disables the affected operations or replaces them with a version that treats close numbers as identical (defining an epsilon).
I was avoiding this discussion but I wanted to just add one more comment. The FPU has a state that has an affect on the precision. In other words... when the FPU is in various states you get a different rounding value. You can control this state with _controlfp_s
Printer DLL and other libraries outside of your control could potentially change the thread FPU state causing your std::map to contain multiple floating point numbers from the same calculations. Unfortunately on Windows user-applications cannot always control third-party DLL from loading into your process. Those DLL could modify and then fail to reset the floating point state.
The answer is "Yes" what you are proposing would work 99% of the time or in "laboratory" conditions where you control both the hardware and software. But if you tried to ship out a commercial product using the above technique... you will almost certainly have a small percentage of the conditions I described above.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
What is the recommended way to listen for a key press globally? At first, adding an infinite loop came to mind (for(;;), or while(true)), but these are bad choices, as they eat a lot of CPU, and adding sleep will cause to lose some of the key press events.
I want to make it to check any key (or key combination), to see what is pressed on Windows OS.
It depends if "globally" applies to the system (user session) or an application. For an application it depends on the type (console or GUI). With GUI applications it depends also if you want to catch all / multiple or only a single / few key combinations.
This function will be called from Java, which app will be minimized, or maybe running in the background. The app won't be focused, so yes, I need it for the entire user session, even if another application is focused, I want it to still register the key press and do something in case a key I randomly choose is pressed. I will make some profiles: profile 1 has key "A", profile 2 has key "CTRL + A", those combinations will be changeable.