Errors, bugs, questions - page 2116

[A100]

The function arguments are not calculated from right to left

int i = 0;
int _etLastError() { return i; }
int _tringGetCharacter( string, int ) { i = 5041; return 0; }
void OnStart()
{
    string abc = "ABC";
    ResetLastError();
    Print( ::StringGetCharacter( abc, 1024 ), ":", GetLastError()); //(*)слева направо
    Print(   _tringGetCharacter( abc, 1024 ), ":", _etLastError()); //   справа налево
}

String result (*) : 0:5041

Expected in both cases: 0:0

[Koldun Zloy]

A100:

The function arguments are not calculated from right to left

String result (*) : 0:5041

It was expected in both cases: 0:0

This is not an error. The compiler decides by itself in which order to calculate the arguments.

You just have to take it into account.

[A100]

Koldun Zloy:

This is not an error. The compiler decides for itself in which order to compute the arguments.

The error is as follows: until recently, the order was strictly defined by https://www.mql5.com/ru/forum/1111/page2040#comment_5858419(note the date and the extract from the documentation: guaranteed). Then the order was quietly changed (including in the documentation), and it could be changed in a civilized way - via inline https://www.mql5.com/ru/forum/1111/page2042#comment_5860752. But how should the user know about it? Should the user guess it? Or before using any tool, look through the documentation?

[A100]

Compilation errors and more

#define MACRO( X )      #X
void OnStart()
{
        Print( MACRO( AC/DC    )); //нормально
        Print( MACRO( AC\\DC   )); //error: '\' - illegal escape sequence
        Print( MACRO( ABC\nDEF )); //error: '\' - illegal escape sequence
        Print( MACRO( 'ABC'    )); //error: '' - single quote needed
        Print( MACRO( "ABC     )); //error: '' - double quotes are needed
        Print( MACRO( "ABC"    )); //Результат: ABC вместо "ABC"
        Print( MACRO( '"'ABC   )); //нормально
}

[Koldun Zloy]

A100:

The mistake is this: until recently, the order was strictly defined by https://www.mql5.com/ru/forum/1111/page2040#comment_5858419(note the date and excerpt from the documentation: guaranteed). Then the order was quietly changed (including in the documentation), and it was possible to change it in a civilized way - via inline https://www.mql5.com/ru/forum/1111/page2042#comment_5860752. But how should the user know about it? Should the user guess it? Or look through the documentation before using any tool?

You just don't have to write code that depends upon the order of calculating arguments.

In C++ the compiler has a right to inline a function even if it does not have the inline keyword.

In MQL there is no inline keyword, the compiler inserts functions only at its discretion.

The order of calculations from right to left was apparently due to the fact that arguments in this order are placed on the stack,

but they may be passed through registers as well.

And for built-in functions, there is no passing of arguments as such at all.

[A100]

Koldun Zloy:

1. You just don't need to write code that depends on the order in which the arguments are calculated.

2. In C++, the compiler has the right to inline a function even if it doesn't have the inline keyword.

3. In MQL there is no inline keyword, the compiler only embeds functions at its own discretion.

4. The order of calculations from right to left seems to be connected with the fact that arguments are put on the stack in this order,

but they can also be passed through registers.

5. And there is no argument passing for built-in functions at all.

1. Why shouldn't it be so if the reverse order is guaranteed in the documentation and the code is simpler and clearer in this case? We might as well deny using 5 + (2*3) operation priorities and demand that parentheses (5 + (2*3)) be put everywhere - in case it is suddenly changed

2. The C++ compiler imposes certain requirements on the embedded functions, which rules out such a situation https://www.mql5.com/ru/forum/1111/page2136#comment_6454818.

3. this is how it was proposed to be introduced

4. In registers (unlike the stack), arguments can be placed in any order, including the reverse order

5. It's not the order of passing that matters - it's the order of calculating arguments, and this is the order of any function with more than one argument. And C++ takes it into account before making (or not making) a function inline (see item 2)

[Koldun Zloy]

A100:

1. Why not, if the reverse order is guaranteed in the documentation and the code is simpler and clearer. We might as well deny using 5 + (2*3 ) and demand to put parentheses (5 + (2*3)) everywhere - in case it is suddenly changed

2. The C++ compiler imposes certain requirements on the embedded functions, which rules out such a situation https://www.mql5.com/ru/forum/1111/page2136#comment_6454818.

3. this is how it was proposed to be introduced

4. In registers (unlike the stack), arguments can be placed in any order, including the reverse order

5. It's not the order of passing that matters - it's the order of calculating the arguments, and this is the case for any function with more than one argument. And C++ takes it into account before making (or not making) a function inline (see point 2)

3. I don't know what that gets you. Do you want to prohibit the compiler from embedding functions without explicitly specifying inline?

2. I don't know what you mean.

4. I was just suggesting what that order and its cancellation was related to. I don't think it was done by accident and it will always be so from now on. There is nothing terrible about it.

5. You are mistaken. In C++, the order of calculating arguments is not defined.

1. I have been writing in C++ for many years and have never found this to be a problem.

[A100]

Koldun Zloy:

3. I don't know what this will do for you. Do you want to prevent the compiler from embedding functions without explicitly specifying inline?

4. I merely suggested what the order and its abolition was about. I don't think it was done by accident and it will always be so now. There's nothing horrible about it.

5. You are mistaken. In C++, the order of calculating arguments is undefined.

3. I was suggesting that the compiler shouldn't be allowed to change the order of calculating arguments for functions without inlines.

5. The order of calculation is defined by the implementation (the compiler) and it is quite concrete (either from right to left or from left to right), and here, for instance:

void OnStart()
{
    ResetLastError();
    Print( GetLastError(), ":", StringGetCharacter( "abc", 1024 ), ":", GetLastError());
}

it's not clear which order is 2-1-3 or 2-3-1 or whatever.

Result: 5041:0:5041.

Expected: 0:0:5041 from left to right or

5041:0:0 from right to left

[fxsaber]

A100:

it is not clear which order is 2-1-3 or 2-3-1 or whatever

I don't understand why write code that is obviously ambiguous?

[A100]

fxsaber:

I don't understand why write code that is obviously ambiguous?

A similar question for you https://www.mql5.com/ru/forum/1111/page2037#comment_5842347