The collapsing "2.3 * 10 = 22" produced by multiplying float and int

The simpler it is, the more it cannot be ignored
Type forced conversion must 　 Be careful ！　 Be careful ！　 Be careful ！

It took me three days' work to realize and learn from the above two days' conclusion .
sometimes , Whether you are careful or not , The pit is right there , There are enough people stepping on it , Maybe it will be filled up .
At work , Assigned to a bug, Briefly describe ： The program is huge , from QT To write , Cross platform , Support ubuntu and windows, One of the modules needs to control the Hikvision camera , The code contains Haikang's SDK.bug The phenomenon is that the specified camera focusing multiple and focal length cannot be set , The performance is that the camera is blurred , Unable to shoot normally , And Only in windows Next happen .
This paper consists of the following parts ：

• Debugging steps
• SDK verification
• 2.3 * 10 = 22

Debugging steps

Engineering code defects

bug Just got it , Read the code , An obvious flaw was exposed ：

• Open loop code

What is open loop code ?
Simple view , This part of the code is like this ：

Defects are ３：

1. Did not judge whether the set value is legal
2. Failed to check whether the setting was successful
3. There is no defense mechanism , There is no method to deal with setting failure

Then add ：

• Legality check
• Start timing cycle inspection
• Failed to reset the check in the timer

Suspected SDK defects

Same code , Behave differently in different systems .
ubuntu 14.04 : normal
windows7 : ** abnormal **
Using exclusion , The logical processing in the code is consistent , The only difference is Haikang's sdk, One is linux64 edition , One is win32 edition .
A load at runtime .so library , A load dll.
Then come and find SDK It's my fault

SDK verification

Here slightly , See ：

2.3 * 10 = 22

Check it out , Finally, compare with your own verification sdk Of demo And engineering code , The most suspicious discovery is ,　 Focusing multiple （zoom value ） There are differences in the treatment of , verification demo You can use float, And the project code will force conversion int, Easy to display and process , But I just didn't think , This forced transfer is the problem , To be exact , It is the processing under different systems that is the cause of the problem .
List the culprits first ：
zoom = rOpticalZoomLevelP * 10;

Let's take a look at the declaration and definition of variables ：
int zoom;
float rOpticalZoomLevelP = 0.0f;

Use qDebug() Print found ：
rOpticalZoomLevelP*10 Before rOpticalZoomLevelP The value is 2.3
After that, the assignment to zoom after ,zoom yes 22.
in other words :
2.3 * 10 = 22？？？

ubuntu Next

System ：ubuntu16.04
gcc edition ：gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10)
demo:

int main(int argc, char　**argv)
{
    
	float a = 2.3f;
    int b =0;
    b = a*10;
    printf("b ------>%d\n",b);
    return 0;
}

result:

windows7 Next

System ：windows7
gcc edition ：MinGW 4.9.1 32bit MinGW
demo:

int main(int argc, char　**argv)
{
    
	float a = 2.3f;
    int b =0;
    b = a*10;
    printf("b ------>%d\n",b);
    return 0;
}

result:
b -------> 22

The cause of the problem is unknown , But you can avoid , Use qRound() function :

zoom = qRound(qreal(rOpticalZoomLevelP*10))

reason

Why does this happen , because a It's a float Data of type , We see it as 2.3, But it doesn't have to be in memory 2.3, It can be 2.29999999999999999, perhaps 2.30000000000000001, Because the range of floating point type is -2^128 ~ +2^128, That is to say -3.40E+38 ~ +3.40E+38;