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
Of course you do.
Any programmer who respects himself and his programs will not let things run their course. In MQL4, if you do not use #property strict, you can refer to an array with size 10 by index 20. And nothing will happen - the program will continue to work, but it is up to the programmer to decide what to use next. If he is smart, he will certainly check and control everything, so as not to get values outside the array, but if he does it "roughly", he does not think about such control, and "the main thing is that it works, but how it works - somehow...".
The majority of users, who haven't bothered with this, have been complaining about "bad, evil and complicated MQL5", because it does not allow them to fake their own creations as before. But those who originally thought and created code with checks and control of received data, didn't notice any difference in complexity of languages, and now wonder - "where's the complexity - it's the same...".
Nikolai, don't worry about MQL4, everything is fine there. The topicstarter fills the arrays as he likes. Everything.
Of course you do.
Any programmer, who respects himself and his programs, will not let things slide. In MQL4, if you don't use #property strict, you can refer to an array with size 10 by index 20. And nothing will happen - the program will continue to work, but it is up to the programmer to decide what to use next. If he is smart, he will certainly check and control everything, so as not to get values outside the array, but if he does it "roughly", he does not care about this control, and "the main thing is that it works, and how - somehow...".
The majority of users, who haven't bothered with this, have been complaining about "bad, evil and complicated MQL5", because it does not allow them to fake their own creations as before. But those who originally thought and created code with checking and controlling received data, didn't notice any difference in complexity of languages, and now wonder - "where's the complexity - it's the same...".
Bummer!
Well, Petr, thanks to MQL5 strictness, you have a chance to put the code in relative order and clear the trash pile.
You can even try to compile the fixed code with #property strict back to MQL4 and maybe it will work much faster on MT4
Bummer!
Well, Peter, thanks to the strictness of MQL5, we have a chance to put the code in relative order and clear the trash piles.
You can even try to compile the fixed code with #property strict back in MQL4 and, perhaps, it will work much faster in MT4
This is how, a priori, you decided that my code is full of rubbish.
Let me explain: the kernel is filled in stages, in several steps. If when declaring array in MT5 there is rubbish in it (which I didn't know), then during first steps of kernel building in functions, there is an overflow outside the array, because instead of pointers to variables, I refer to one kernel cell through another. If it contains zero, it's OK, and it gets the right value in the second run, but if it contains rubbish, a critical error occurs.
Is that clear to you?
Peter, I don't know what you mean.
Exactly, you don't understand. You're comparing my tasks to your own...
I don't have any overflows. Consider the specifics of my technology (forgot you're ignoring it). If you use another cell in the array as a pointer to one cell, and there's rubbish in it, then you're out of the array. The problem is that in order for the cell you're referring through to get the correct value, you have to go to the second round of kernel construction. And on the second round, the value will be correct. But you don't get to the second round because of a critical error.
All this is due to rubbish in the array being declared.
So, we need to invent mechanisms to clear the two-dimensional array (kernel) at the stage of the first size setting (building the regular area) and at the stage of the second resizing of the kernel, when building the user area.
Exactly, you don't understand. Compared, my tasks and your own...
Go ahead and create a monologue - 10 more posts in a row.
This is how, a priori, you decided that my code is full of rubbish.
Let me explain: the kernel is filled in stages, in several steps. If when declaring array in MT5 there is rubbish in it (which I didn't know), then during first steps of kernel building in functions, there is an overflow outside the array, because instead of pointers to variables, I refer to one kernel cell through another. If it contains zero, it's OK, and it gets the right value in the second run, but if it contains rubbish, a critical error occurs.
Is that clear to you?
It's not like thatat all. It's not rubbish that's to blame, but absence of #property strict in mql4. Without it, you get 0 instead of array overrun, and in mql5 it's already a critical error. Probably, it's better to check the array length instead of the contents of a non-existing array index.
Retag is not like that at all. It's not rubbish that's to blame, it's the lack of #property strict in mql4. Without this gimmick you get 0 instead of array overrun, and in mql5 already critical error. Probably, it's better to check the array length instead of the contents of a non-existing array index.
Out of bounds occurs because there is rubbish in the indicating cell.
For example:
Initial:
G_CORE[Object][Kanvas] = -123423452345; (rubbish)
G_CORE[Window][His_canvas]= -452345; (rubbish)
//-----------------------------------------------------------------
Result is out of array.
To reiterate. Some cells have zero values in MT4 and are filled in the second round in the first stage of core filling.
In MT5, due to rubbish in cells, there is a critical error on the first round.
If the cells in the array had zeros, there would be no error and the kernel would fill sequentially (as it should).
Here is a more accurate example:
The first round of kernel construction. In one of the functions:
Out of bounds occurs because there is rubbish in the indicating cell.
For example:
Initial:
G_CORE[Object][Kanvas] = -123423452345; (rubbish)
G_CORE[Window][His_canvas]= -452345; (rubbish)
//-----------------------------------------------------------------
Result is out of array.
To reiterate. Some cells have zero values in MT4 and are filled in the second round in the first stage of core filling.
In MT5, due to rubbish in cells, there is a critical error on the first round.
If there were zeros in the array cells, there would be no error and the kernel would be filled sequentially (as it should be).
The array non-initialization is entirely the kodopistael's fault. Look for the error in your own environment. Rebuild your algorithm.