Ошибки, баги, вопросы - страница 2116

[[Удален]]

A100:

Ошибка заключается в следующем: еще недавно порядок строго определялся https://www.mql5.com/ru/forum/1111/page2040#comment_5858419 (обратите внимание на дату и выдержку из документации: гарантируется). Потом порядок потихому поменяли (в том числе в документации), причем поменять его можно было цивилизованно - через inline https://www.mql5.com/ru/forum/1111/page2042#comment_5860752. А как пользователь должен узнать об этом? Догадаться? Или перед использованием любого инструмента смотреть документацию?

Просто не нужно писать код, зависящий от порядка вычисления аргументов.

В С++ компилятор имеет право встраивать функцию даже если у неё нет ключевого слова inline.

В MQL нет ключевого слова inline, компилятор встраивает функции только по своему усмотрению.

Порядок вычисления справа налево видимо был связан с тем, что аргументы в таком порядке помещаются в стек,

но ведь они могут быть переданы и через регистры.

А для встроенных функций вообще нет передачи аргументов, как таковой.

[A100]

Koldun Zloy:

1. Просто не нужно писать код, зависящий от порядка вычисления аргументов.

2. В С++ компилятор имеет право встраивать функцию даже если у неё нет ключевого слова inline.

3. В MQL нет ключевого слова inline, компилятор встраивает функции только по своему усмотрению.

4. Порядок вычисления справа налево видимо был связан с тем, что аргументы в таком порядке помещаются в стек,

но ведь они могут быть переданы и через регистры.

5. А для встроенных функций вообще нет передачи аргументов, как таковой.

1. Почему не нужно, если обратный порядок гарантировался документацией и при этом код получался более простым и понятным. С таким же успехом можно отрицать использование приоритета операций 5 + 2*3 и требовать расставлять везде скобки (5 + (2*3)) - на случай если его вдруг поменяют

2. С++ компилятор предъявляет к встраиваемым функциям определенные требования исключая подобную ситуацию https://www.mql5.com/ru/forum/1111/page2136#comment_6454818

3. Так его и предлагалось ввести

4. В регистры (в отличие от стека) аргументы можно поместить в любом порядке в том числе и в обратном

5. Важен порядок не передачи, а вычисления аргументов. А он есть для любой функции с более чем одним аргументом. И С++ учитывает это перед тем как сделать (или не сделать) функцию встраиваемой (см.п.2)

[[Удален]]

A100:

1. Почему не нужно, если обратный порядок гарантировался документацией и при этом код получался более простым и понятным. С таким же успехом можно отрицать использование приоритета операций 5 + 2*3 и требовать расставлять везде скобки (5 + (2*3)) - на случай если его вдруг поменяют

2. С++ компилятор предъявляет к встраиваемым функциям определенные требования исключая подобную ситуацию https://www.mql5.com/ru/forum/1111/page2136#comment_6454818

3. Так его и предлагалось ввести

4. В регистры (в отличие от стека) аргументы можно поместить в любом порядке в том числе и в обратном

5. Важен порядок не передачи, а вычисления аргументов. А он есть для любой функции с более чем одним аргументом. И С++ учитывает это перед тем как сделать (или не сделать) функцию встраиваемой (см.п.2)

3. Не знаю, что это Вам даст. Вы хотите запретить компилятору встраивать функции без явного указания inline?

2. Не понимаю о чём Вы.

4. Я всего лишь предположил, с чем связан был такой порядок и его отмена. Думаю, что это сделали не случайно, и теперь так будет всегда. Ничего ужасного в этом нет.

5. Вы ошибаетесь. В C++ порядок вычисления аргументов не определён.

1. Я много лет пишу на C++ и никогда не считал это проблемой.

[A100]

Koldun Zloy:

3. Не знаю, что это Вам даст. Вы хотите запретить компилятору встраивать функции без явного указания inline?

4. Я всего лишь предположил, с чем связан был такой порядок и его отмена. Думаю, что это сделали не случайно, и теперь так будет всегда. Ничего ужасного в этом нет.

5. Вы ошибаетесь. В C++ порядок вычисления аргументов не определён.

3. Я предлагал запретить компилятору менять порядок вычисления аргументов для функций без inline 

5. Порядок вычисления определяется реализацией (компилятором) и он вполне конкретный (либо справа налево, либо слева направо), а здесь например:

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

вообще не понятно какой порядок 2-1-3 или 2-3-1 или какой еще

Результат:   5041:0:5041

Ожидалось:      0:0:5041       слева направо или

                   5041:0:0            справа налево

[fxsaber]

A100:

вообще не понятно какой порядок 2-1-3 или 2-3-1 или какой еще

Не понимаю, зачем писать заведомо неоднозначный код?

[A100]

fxsaber:

Не понимаю, зачем писать заведомо неоднозначный код?

К Вам аналогичный вопрос https://www.mql5.com/ru/forum/1111/page2037#comment_5842347

[fxsaber]

A100:

К Вам аналогичный вопрос https://www.mql5.com/ru/forum/1111/page2037#comment_5842347

Там была однозначность.

[A100]

fxsaber:

Там была однозначность.

Какая однозначность, если порядок вычисления операндов неопределен?

[fxsaber]

A100:

Какая однозначность, если порядок вычисления операндов неопределен?

Когда неопределен, тогда и не использую. А когда определен - использую.

Даблы складываются слева-направо. Ничего здесь не поменяют.

[A100]

fxsaber:

Когда неопределен, тогда и не использую. А когда определен - использую.

Неопределен в том смысле что не документирован и в любой момент поменять могут. А если был бы документирован, то и документацию поменять не проблема