Errors, bugs, questions - page 493

[Ilyas]

Lodar:
I don't argue.
but this way
there's a rounding anyway, should it do that?

Look at the type of the round() function. This is a rounding function, not a type conversion function.

[[Deleted]]

Developers.

I accidentally looped the processing of ticks in Expert Advisor, after which a critical error about stack overflow appeared.

The problem is that there is no specific information in the message about what and where exactly it happened.

I suggest to clarify the text of this message, if possible you want to catch such problems (such as calling a class method from a called method) at the compilation stage.

[Валерий]

MoneyJinn:

The reason why iCustom() assigns arbitrary values to those buffer cells, which in reality were not filled with anything, is unclear to me, as well as the reason why it cannot be avoided in any way.

I suppose it has something to do with allocation of memory for the corresponding data array of the indicator buffer.

Such an operation of iCustom(), when it is impossible to determine the origin and truth of the data, seems inadmissible to me and creates additional risks for the user.

If iCustom() assigns arbitrary, inconsistent with the real values to the buffer cells anyway,

why doesn't it assign values equal to Empty_Value to these cells as it is implemented in MT4?

Then at least their status would be clear.

No one but the author can decide what the unused buffer values should be filled with. You say Empty_Value, but I, for example, need it to be 0, or something else. Whatever value you want, initialize it with it.

[Vladimir Gomonov]

Interesting:

Developers.

..........., if possible want to catch problems like this (such as calling a class method from a called method) at compile time.

I'm against it. It would make the compiler inordinately complicated and therefore less reliable.

It is up to the programmer to track incorrect recursion.

But I would like the error message to contain the name of the function that has overflowed the stack.

[Andrey Vasiliev]

Valmars:
No one but the author can decide what unused buffer values should be filled with. You say Empty_Value, but I, for example, want it to be 0, or something else. Whatever value you want, initialize it with it.

This is correct and logical. But the problem is that buffer cells which the user has not filled with anything (!), the iCustom() function periodically fills with arbitrary rubbish at its own discretion. Is it supposed to be like that?

[Renat Fatkhullin]

MetaDriver:

I'm against it. It would make the compiler exorbitantly complex and therefore less reliable.

It's up to the programmer to track incorrect recursion.

But I would like the error message to contain the name of the function that has overflowed the stack.

Yes, we purposely don't complicate the working engine (it's native 32/64 after all) with meta-information.

Recursion is usually easy to catch - it depends directly on the size of local variables, and there are very few such places in a program.

[Renat Fatkhullin]

MoneyJinn:

This is correct and logical. But the problem is that the buffer cells, which the user hasn't filled (!), iCustom() function fills at its discretion with random rubbish. Is it supposed to be like this?

If the custom indicator doesn't fill its buffer correctly, this custom indicator is guilty.

And if this custom indicator sends its results through iCustom, it is doubly guilty, as it misleads users.

[Andrey Vasiliev]

Renat:

If a custom indicator doesn't fill its buffer correctly, it means that this custom indicator is guilty.

And if this custom indicator gives out its results through iCustom, it is doubly guilty, as it misleads users.

I understand your mindset. I wish you success.

[Stanislav Korotky]

Renat:

If a custom indicator doesn't fill its buffer correctly, it's this custom indicator that's to blame.

And if this custom indicator sends out its results through iCustom, it is doubly guilty, because it misleads users.

I still don't understand, what prevents you from making the program not only efficient, but also convenient? If I remember correctly, the reasoning for absence of built-in initialization of indicator buffers in 5 is to optimize the speed. In this case indicator developer has to code by himself the very initialization strings ("zeros"), which previously in fours was performed by the kernel. So, the resulting efficiency doesn't seem to get better, and the usability suffers. But since it was decided to do it this way for some reason, why not to make it optional? I.e. we could introduce one more #property, specifying whether the buffers should be initialized automatically or not.

To summarize, I'll repeat the idea I've already expressed once: the task of the platform, which is MT, is to protect the user (the programmer) from possible "mistakes" as much as possible.

[Vladimir Gomonov]

MoneyJinn:

This is correct and logical. But the problem is that buffer cells that the user has not filled (!) with anything, iCustom() periodically fills with arbitrary rubbish at its own discretion. Is it supposed to be like that?

Actually, it's a common rule: initializing arrays is at the user's discretion. An uninitialized array contains random values from memory allocated to it. The user may have a good reason not to initialize the array unnecessarily (to save time, for example). I sometimes save time this way when I'm sure I won't have to read and "eat" that rubbish before the real information is there.

I don't see any malice on MQ's side. I would rather object if they "prophylactically" start slowing down my programs.