Features of the mql5 language, subtleties and tricks - page 202
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
The standard functions receive the arguments from left to right.
Custom functions receive the arguments from right to left.
Result.
Is this the way it should be?
Is that the way it's meant to be?
This is a UB that cannot be relied upon. I.e. one must explicitly avoid situations where the logic of a program depends on the order in which the arguments are evaluated
The staff functions receive arguments from left to right.
Here is a refuting example:
Result: 2 1
This is a UB that cannot be relied upon. I.e. we must explicitly avoid situations where the logic of a program depends on the order in which the arguments are evaluated
Here's a refuting example:
It turns out that everything is unstable with custom ones. With custom ones, everything is unstable from the beginning.
It turns out that everything is unstable with the standard ones. With custom ones, it is unambiguous from the start.
The difference is that there are regular functions (from right to left) and inline functions (undefined order).
inline functions are not functions at all, i.e. they cannot have an address. From this point of view, there is no difference between regular and custom functions, so for example, it's unclear why the arguments of the simplest custom function (which is in essence inline) are always calculated from right to left. I do not exclude that in the future for inline functions the order may change, so
I suggested at one time to introduce an inline keyword for safe use of the order of calculations:
Forum on trading, automated trading systems and trading strategy testing
Errors, bugs, questions
A100, 2017.10.05 14:30
This once again demonstrates the usefulness of the C++ inline keyword (there was an opinion here that it was supposedly obsolete).
Among other things, inline actually means that the programmer does not use the computation order of the function parameters and if the compiler decides to make the inline function inline, then the compiler can use the forward computation order as more efficient (the reverse computation order is obviously only efficient for called functions).
At the same time, if the compiler decides to embed a non-inline function, it should use the (general) reverse order of evaluation, even if this leads to a loss of efficiency (because the programmer assumed this order without having declared the function inline)
inline would also be appropriate in MQL, where the computing order cannot be controlled explicitly
The difference is that there are normal functions (from right to left) and inline functions (undefined order).
Inline functions are not functions at all, i.e. they cannot have an address. From this point of view, there is no difference between regular and custom functions, so for example, it's unclear why the arguments of the simplest custom function (which is in essence inline) are always calculated from right to left. I do not exclude that in the future for inline functions the order may change, so
I suggested at one time to introduce the keyword inline for safe use of calculation order:
Thanks for the clarification, I hadn't thought of inline.
Such an option does not affect the result.
Thanks for the clarification, I hadn't thought of the inline.
This option does not affect the result.
It has no effect now, because it kind of does not exist in MQL
and in the future it may have a real meaning, otherwise why would it be introduced?
It has no effect now, because in MQL it is kind of absent now
and in the future it may have a real meaning, otherwise why would it have been introduced?
As far as I remember from the help to the version, it was introduced as a stub to allow to inline *.h files.