Ошибки, баги, вопросы - страница 3478
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
тут совсем не в && дело, а в f(a).Method(f(b)).
Так вот, в c++17 добавили:
In a function-call expression, the expression that names the function is sequenced before every argument expression and every default argument.
И все стало, так как и хочет A100.
Да, очевидную вещь закрепили в современном стандарте (since C++20)
И почему мы должны руководствоваться устаревшим ПО (until C++17) ??
Википедия не предоставляет источника для этого утверждения об ассоциативности. Ты сам это написал? ;-)
https://en.cppreference.com/w/cpp/language/operators#Rarely_overloaded_operators
Да. И этот пример либо баг, либо специально задокументированное поведение с объяснением причин.
Это не баг, это операторы разные.
(until C++17) УСТАРЕЛО!
Почему это сразу устарело? С++20 до сих пор не все компиляторы в полном объеме поддерживают. По сути, в основном, С++14/17 везде используют. 20-ый редкость редкая.
(until C++17) УСТАРЕЛО!
Ну давай же. MetaQuotes не следует никаким стандартам MQL и, конечно же, C++17. MQL основан на C++, ни больше, ни меньше.
В любом случае, только MetaQuotes может сказать что-то полезное по этому вопросу. Мое мнение: это не ошибка, порядок последовательности не определен, и на него не следует полагаться. Хотя я понимаю вашу логическую точку зрения.
Выхожу из обсуждения. Теперь Вики авторитет.
Завтра новая лютая ошибка (только обнаружил) - готовьтесь
Это не баг, это операторы разные.
Утверждаете, что эти два оператора не являются завуалированными методами? Где почитать про это?
A100 # :
Cуществует простое доказательство на базе MQL, что && не равносильно operator&& - это разный результат:
Вы должны быть честными с приоритетом.