You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
This warning should not be given, because the ObjectGetDouble function passes a reference and the if statement checks the truth returned by both calls, and hence only if both functions return true then these variables are handled, which means that both variables cannot be not set to the correct value.
The compiler doesn't expand its mind enough to make sure that these variables will necessarily be initialized as a result of an ObjectGetDouble call. Try writing your own instead, where the value for the input parameter passed by reference will be set explicitly. What will the compiler say?
Rashid, it's not really "consciousness" at all, it's mathematics.
Rashid, it's not really "consciousness" at all, it's mathematics.
1. There is such a thing as "shortened evaluation of logical expressions".
2. The compiler cannot know for sure if the variable passed in by reference will be populated.
3. A warning is just that, a warning to draw your attention to the possibility of a problem.
Rashid, it's not really "consciousness" at all, it's mathematics.
Ok, let's define such a fusion
Is there a guarantee here that the param variable will be initialized?Ok, let's define such a ffruncture
Is there any guarantee that the param variable will be initialized?This is a function in which the result "param" is NOT changed. So here the warning should be given out 1000% :)
The standard solution here is this: if there is a code execution branch where the value cannot be changed, this function is considered not to change the value. And it will generate a warning.
Rashid, do you want me to take any of the modern C++ and C compilers and compile such code and I'm sure none of them will give a lefty warning.
Moreover, if you have such "problems" with detection of such things, suddenly you start to have a very strong doubt that there is no optimization at all as such. Or is there?
Rashid, you want me to take any of the modern C++ and C compilers and compile similar code and I'm sure none will give a lefty warning.
What are we arguing about? w0 don't put
PS There will definitely be a message (maybe a few lines below)
This is clearly not an improvement, especially if there are such "problems" with detection of such things, then a BIG doubt creeps in that there is no optimisation at all as such. Or is there?
If you look at the help for ObjectGetDouble:
Returns true or false depending on the success of the function. If successful, the value of the property is placed in the destination variable, passed by reference by the last parameter.
Hence, we conclude that the filling of the receiving variable is not guaranteed in case of any error. That's why the compiler's message is valid.
IMHO.
Something is out of sync in the latest build.
Doing a small EA:
Running the tester,
2011.02.22 11:54:21 Core 1 2011.02.07 00:00:00 Everything is OK!
I make changes to my EA:
I compile it, run the tester, it responds:
2011.02.22 11:57:55 Core 1 2011.02.07 00:00:00 All normal!
It only helps to restart the terminal.
Something is out of sync in the latest build.
Doing a small EA:
Running the tester,
2011.02.22 11:54:21 Core 1 2011.02.07 00:00:00 Everything is OK!
I make changes to my EA:
I compile it, run the tester, it responds:
2011.02.22 11:57:55 Core 1 2011.02.07 00:00:00 All normal!
It only helps to restart the terminal.