Features of the mql5 language, subtleties and tricks - page 202

 
Comments not related to this topic have been moved to "Questions from MQL5 MT5 MetaTrader 5 beginners".
 

The standard functions receive the arguments from left to right.

Custom functions receive the arguments from right to left.

double f1()
{
  Print(__FUNCSIG__);
  
  return(0);
}

double f2()
{
  Print(__FUNCSIG__);
  
  return(0);
}

void Func( double, double )
{
}

#define  PRINT(A) Print(#A);  A

void OnStart()
{  
  PRINT(MathMin(f1(), f2()));
  
  PRINT(Func(f1(), f2()));
}


Result.

        MathMin(f1(),f2())
        double f1()
        double f2()
        Func(f1(),f2())
        double f2()
        double f1()


Is this the way it should be?

 
fxsaber:

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

 
fxsaber:

The staff functions receive arguments from left to right.

Here is a refuting example:

string f1() { Print(1); return NULL; }
string f2() { Print(2); return NULL; }
void OnStart()
{
    StringCompare(f1(), f2());
}

Result: 2 1

 
Andrei Trukhanovich:

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

A100:

Here's a refuting example:

It turns out that everything is unstable with custom ones. With custom ones, everything is unstable from the beginning.

 
fxsaber:

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


 
A100:

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.

__forceinline void Func( double, double )

Such an option does not affect the result.

 
fxsaber:

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

#define inline

and in the future it may have a real meaning, otherwise why would it be introduced?

 
A100:

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.

 
As for the order of calling functions whose returns are passed as arguments to a function, the c++ standard does not impose requirements on the compiler on the order of their calculation, they can be called in any sequence(https://en.cppreference.com/w/cpp/language/eval_order). How the analogy is applicable to mql is up to the developers, they may or may not have bothered to define it.