Новая версия платформы MetaTrader 5 build 2755: Улучшения в окне котировок и отладчике - страница 42
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Новая версия платформы MetaTrader 5 build 2755: Улучшения в окне котировок и отладчике
fxsaber, 2021.02.14 18:43
Какая-то особенность NULL, что вызывает ошибку компиляции.С точки зрения C++ ошибка при компиляции должна быть в обоих случаях (1) и (2)
А с точки зрения MQL:
Из (4) следует, что если
f(_Symbol ); //(5) ошибка при компиляции
то и
Другими словами, если Вы допускаете, что строка (1) без ошибки - это нормально, то ошибку в (2) тоже можно оправдатьВызов конструктора класса по-умолчанию из параметрического конструктора вызывает деструктор класса на выходе из параметрического конструктора. Есть какие-то запреты на использование такой конструкции или это бага компилятора?
Код, демонстрирующий проблему, прилагаю.
Всё правильно.
Когда Вы в теле одного конструктора вызываете другой конструктор, создаётся ещё один объект и при выходе из конструктора первого объекта он уничтожается.
С точки зрения C++ ошибка при компиляции должна быть в обоих случаях (1) и (2)
А с точки зрения MQL:
Из (4) следует, что если
то и
Другими словами, если Вы допускаете, что строка (1) без ошибки - это нормально, то ошибку в (2) тоже можно оправдатьРазве NULL это такой макрос?
С точки зрения C++ ошибка при компиляции должна быть в обоих случаях (1) и (2)
А с точки зрения MQL:
Из (4) следует, что если
то и
Другими словами, если Вы допускаете, что строка (1) без ошибки - это нормально, то ошибку в (2) тоже можно оправдатьВызов конструктора класса по-умолчанию из параметрического конструктора вызывает деструктор класса на выходе из параметрического конструктора. Есть какие-то запреты на использование такой конструкции или это бага компилятора?
Код, демонстрирующий проблему, прилагаю.
внутри { } вы просто создаете объект, который при выходе из области видимости автоматически уничтожается
можете использовать вот такую конструкцию
Будет зависеть от вызываемой функции:
Я рекомендую воздержаться от использования модулей, мы планируем изменение в их работе, теоретически могут возникнуть проблемы в совместимости версий.
Разве NULL это такой макрос?
Если это было бы так, то была бы другая ошибка:
Компилятор в случае (1) проявил одну "гибкость" (не выдав ошибку). А в случае (2) другую: заменив _Symbol + NULL на _SymbolВопрос в том: нужны ли такие "гибкости" или все должно быть строго. А если в одном месте имеет место гибкость, то почему в другом нельзя?
Проблема не в сложении строки и NULL, а в том, что такой вызов
если не может, то остается единственный вызов void f( const string ) {} (*) и ошибки бы не было, а она есть. Поэтому такое объяснение не годится (само себе противоречит)
Более того функция void f( const string& ) {} (**) в MQL вообще никогда не будет вызвана. В любом выражении всегда будет вызываться (*), что как пример происходит в случае (1)
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Хочется STL подобного
A100, 2019.06.09 21:30
А в чем возможность? В том что (2) нельзя вызвать даже явно? В этом гибкость заключается?
функция void f( const string& ) {} (**) в MQL вообще никогда не будет вызвана.
Иногда функции, которые заведомо не могут быть вызваны, добавляются для большего контроля исходника.
Иногда функции, которые заведомо не могут быть вызваны, добавляются для большего контроля исходника.
На мой взгляд общий строгий единый подход важнее отдельных локальных сиюминутных удобств ему противоречащих