Forced array clearing in MT5? - page 2

 
Artyom Trishkin:

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...".

The code has shown that division by zero without #property strict is allowed and the planet is not collapsing into a black hole, but sometimes one wants to divide by zero, but they don't let one do it
 
Алексей Тарабанов:

Nikolai, don't worry about MQL4, everything is fine there. The topicstarter fills the arrays as he likes. Everything.

Artyom Trishkin:

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

 
Nikolai Semko:

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?

 
Nikolai Semko:
Peter, I don't know what you mean.
...

Exactly, you don't understand. You're comparing my tasks to your own...

 
...
If you have an overflow happening, look for errors in yourself.
And if there is rubbish, it is your rubbish that you have not cleaned up.

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.

 
Реter Konow:

Exactly, you don't understand. Compared, my tasks and your own...

Go ahead and create a monologue - 10 more posts in a row.

 
Реter Konow:

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.

 
Alexey Viktorov:

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:

G_CORE[Объект][Канвас] = G_CORE[Окно][Его_канвас];

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:

int Ширина_канваса = G_CORE[G_CORE[Окно][Его_канвас]][_X_SIZE];

Если G_CORE[Окно][Его_канвас] = 234523452345; (мусор) то ошибка. А если бы G_CORE[Окно][Его_канвас] = 0; Ошибки нет, и ядро продолжает нормально строится.
 
Реter Konow:

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.

Reason: