Особенности языка mql5, тонкости и приёмы работы - страница 202
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Штатные функции получают аргументы слева направо.
Пользовательские - справа налево.
Результат.
Так задумано?
Так задумано?
Это UB на который нельзя опираться. Т.е. надо явно избегать ситуций, когда логика программы зависит от порядка вычисления аргументов
Штатные функции получают аргументы слева направо.
Вот опровергающий пример:
Результат: 2 1
Это UB на который нельзя опираться. Т.е. надо явно избегать ситуций, когда логика программы зависит от порядка вычисления аргументов
Вот опровергающий пример:
Получается, что со штатными все нестабильно. С пользовательскими - однозначно с самого начала.
Получается, что со штатными все нестабильно. С пользовательскими - однозначно с самого начала.
Разница в том, что есть обычные функции (справа налево) и inline функции (неопределенный порядок).
inline функции это и не функции вовсе, т.е. у них адреса быть не может. С этой точки зрения разницы между штатной и пользовательской нет никакой, поэтому например непонятно почему у простейшей пользовательской функции (которая по сути inline) аргументы вычисляются всегда справа налево. Не исключаю, что в будущем для inline функций порядок может поменяться, поэтому
я в свое время предлагал ввести ключевое слово inline для безопасного использования порядка вычислений:
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Ошибки, баги, вопросы
A100, 2017.10.05 14:30
Это лишний раз свидетельствует о пользе ключевого слова С++ inline (здесь было мнение что оно якобы устаревшее).
Помимо прочего inline фактически означает отказ программиста от использования порядка вычисления параметров функции и если компилятор решит сделать inline функцию встраиваемой, то компилятор может использовать прямой порядок вычисления как более эффективный (обратный порядок вычисления очевидно эффективен только для вызываемых функций).
В то же время если компилятор решит сделать встраиваемой не inline функцию то он должен использовать (общий) обратный порядок вычисления даже если это ведет к потере эффективности (потому что программист заложился на это порядок не объявив функцию inline)
inline был бы к месту и в MQL, где порядком вычисления нельзя управлять явно
Разница в том, что есть обычные функции (справа налево) и inline функции (неопределенный порядок).
inline функции это и не функции вовсе, т.е. у них адреса быть не может. С этой точки зрения разницы между штатной и пользовательской нет никакой, поэтому например непонятно почему у простейшей пользовательской функции (которая по сути inline) аргументы вычисляются всегда справа налево. Не исключаю, что в будущем для inline функций порядок может поменяться, поэтому
я в свое время предлагал ввести ключевое слово inline для безопасного использования порядка вычислений:
Спасибо за разъяснение, про инлайн не подумал.
Такой вариант не влияет на результат.
Спасибо за разъяснение, про инлайн не подумал.
Такой вариант не влияет на результат.
Сейчас не влияет, потому что в MQL сейчас его как бы и нет
а в будущем его могут наполнить реальным смыслом, иначе зачем его вводить было
Сейчас не влияет, потому что в MQL сейчас его как бы и нет
а в будущем его могут наполнить реальным смыслом, иначе зачем его вводить было
Насколько помню из справки к версии, ввели как заглушку, что бы можно было *.h файлы инлайнить.