Особенности языка mql5, тонкости и приёмы работы - страница 122
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Результат
Стабильно третий вариант (switch) медленнее второго (указатели на функции). По какой причине такое происходит?
ЗЫ Торможу. Третий быстрее второго. Все норм.
ЗЫЫ Получается, что если есть неизменяемый массив указателей на функции, то быстрее будет, если его заменить на switch.
ЗЫЫ Получается, что если есть неизменяемый массив указателей на функции, то быстрее будет, если его заменить на switch.
Ну в данном случае - это логично, т.к. массив заполнялся динамически, а значит идут постоянные проверки валидности указателей. Хотя могло бы конечно и оптимизироваться...
Вот если бы MQL поддерживал инициализацию массива константными указателями, тогда, возможно, было бы одинаково.
p.s. Ваш код совершенно не читабелен. Я конечно понимаю, что вам удобны эти навороты с макросами, ибо вы сами их писали, поэтому знаете, что они делают. Но для стороннего читателя - это просто головоломка. Зачем выкладывать такое? Думаю вы и сами через полгода вряд ли поймёте, что здесь наворотили ) Хоть бы комментарии делали чтоль...
p.s. Ваш код совершенно не читабелен. Я конечно понимаю, что вам удобны эти навороты с макросами, ибо вы сами их писали, поэтому знаете, что они делают. Но для стороннего читателя - это просто головоломка. Зачем выкладывать такое? Думаю вы и сами через полгода вряд ли поймёте, что здесь наворотили ) Хоть бы комментарии делали чтоль...
Иначе была бы портянка. Более того, экспериментировал с количеством переходов. Без макросов это делать было бы сложно. По поводу доп. комментариев - учту в будущем.
Иначе была бы портянка. Более того, экспериментировал с количеством переходов. Без макросов это делать было бы сложно. По поводу доп. комментариев - учту в будущем.
Иногда гораздо проще разобрать понятную портянку, чем начать разбирать компактный ребус и тут же забросить сиё бесполезное занятие.
Иногда гораздо проще разобрать понятную портянку, чем начать разбирать компактный ребус и тут же забросить сиё бесполезное занятие.
В дополнение к ранее сказанному, одной из самых распростаненных причин несовпадения одинаковых прогонов в Тестере - ошибочная инициализация или ее отсутствие.
Если отсутствие инициализации переменных - просто, то с массивами - несколько сложнее. Чаще всего указать на проблемное место может нахождение ситуаций, где количество элементов массива увеличивается.
Чтобы поймать такие потенциальные проблемы, можно в начале советника вставить такие строки
Если ситуация будет поймана, то в лог будет выведена подробная информация и прогон будет остановлен.
ЗЫ Пример применения.
C ресайзом понятно, я сам часто пользуюсь аналогичным способом, а с инициализацией то что? Как она может быть ошибочной?
Например, перепутаны местами ArrayResize и ArrayInitialize. Или, например, в индикаторе делается ArrayInitialize буфера в OnInit, ошибочно думая, что буфер инициализировался.
Например, перепутаны местами ArrayResize и ArrayInitialize.
ну это совсем детская ошибка. стоит ли её нахождение таких усилий
ну это совсем детская ошибка. стоит ли её нахождение таких усилий
Нахождение любой ошибки требует усилий. Особенно, когда код большой и не свой.