Новая версия платформы MetaTrader 5 build 2085: Интеграция с Python и массовые улучшения в тестере стратегий - страница 19
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Стал замечать, что при запуске теста в последнем обновлении мигает окно. Сейчас решил отловить это окно и оказалось, что теперь сразу после Старта вызывается:
Окно раздражает. Да и смысла перекомпилировать исходники нет.
Сохранение отчета тестирования тоже раздражает своим миганием.
В многозадачной, многопользовательской системе, с поддержкой групповую работы над проектами, отслеживать изменения и перекомпилировать исходники нужно обязательно.
Не в обиду будет сказано, но однозадачные подходы а-ля DOS безнадежно устарели, я давно понял, занимаясь этим много лет назад и не могу даже представить сколько лет должно быть тем, кто этого до сих пор не понял))
Может ли кто-нибудь объяснить записи в журнале 'моего' TesterAgent 'с этого дня?
Can someone explain the log entries of 'my' TesterAgent' from this afternoon?
66 файлов на ~ 65 МБ:
After this in the folder F:\MetaTester\Tester\Agent-0.0.0.0-2001\temp\ I found
66 files at ~65 MB:
как отловили вызовы с флагами?
Тулза от Марка Руссиновича
Результат
Ожидалось во втором случае
Сейчас, когда распечатываешь конец массива, не возможно понять, какие индексы на самом деле выведены.
Ошибочные предупреждения компилятора:
Просьба сделать более подробное предупреждение, с указанием местоположения предыдущего макроса. Иначе бывает трудно его отыскать, когда в исходник включено много файлов - неизвестно в каком именно он находится. Т.е. чтоб было по аналогии с перекрытием имён переменных: see previous declaration of 'MACRO' - щёлкнув на эту строку, попадали бы в нужно место.
Не оправданное предупреждение в данном случае:
Ведь константа NULL является универсальной для разных типов, автоматически преобразующаяся в нужному типу. Об этом и в справке сказано.
Я бы предпочёл использовать NULL вместо false, так более читаемо в коде. Ибо разница между true и false визуально плохо ощущается. Зачастую даже использую return 0 вместо return false для лучшей наглядности. В C++ это не вызывает предупреждений.
А вот ситуация, где должно быть предупреждение, но его нет:
Как же так? Здесь как-раз вопиющее нарушение.
А вот ситуация, где должно быть предупреждение, но его нет:
Как же так? Здесь как-раз вопиющее нарушение.
По-моему, это правильное поведение
А вот здесь полезность предупреждения не совсем понятна
По-моему, это правильное поведение
И уж тем более, одно дело инициализация переменной, когда всё перед глазами. И другое дело, когда вызывается некая функция, находящаяся возможно в какой-то библиотеке, и тип аргумента этой функции нам не виден. Контроль типов - это залог качества и надёжности кода.
А вот здесь полезность предупреждения не совсем понятна
В C++ такое, конечно, не вызывает предупреждений. Но в случае обычных арифметических операций, я считаю, они вполне обоснованны. А вот в случае битовых операций, на мой взгляд, предупреждения не нужны, т.к. там приведение к bool часто используется для проверки на неравенство нулю:
Иначе придётся сильно усложнять запись, нагромождая скобки из-за низкого приоритета битовых операций
Тулза от Марка Руссиновича
скиньте ссылку на нее если не сложно