Ошибки, баги, вопросы - страница 1953
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
В общем я вынужден с прискорбием признать, что компилятор MQL далеко не такой умный, как о нём думал ) Я бы даже сказал - совсем не умный ) Попробовал набросать простенькие примеры, и оказалось что даже если создаётся объект-пустышка, который нигде не используется и ничего не делает, то компилятору на это пофиг. Оптимизации никакой. Сужу чисто по скорости работы. Причём в новых билдах почему-то работает медленнее, чем в старых.
Разработчики в курсе. Но такая оптимизация компилятором далеко не в приоритете решаемых задач.
ЗЫ Есть и такие неоднозначности компилятора.
Разработчики в курсе. Но такая оптимизация компилятором далеко не в приоритете решаемых задач.
Да, но просто удивительно, они столько тут хвастались в прежние годы, что мол подняли качество оптимизатора до небывалых высот, а по факту даже с такими простейшими вещами не справляется. Что уж говорить о более сложных.
Поэтому предлагаю в OnTesterInit добавить возможность изменения сформированной по-умолчанию таблицы проходов:
Я полагаю, сами наборы параметров не хранятся в системе, а вычисляются по уникальному номеру комбинации (сейчас он совпадает с номером прохода). Поэтому можно лишь поменять порядок следования комбинаций, но не их состав. Т.е. в данном случае было бы что-то вроде SwapPasses(long index1, long index2).
Но могу и ошибаться.
Я полагаю, сами наборы параметров не хранятся в системе, а вычисляются по уникальному номеру комбинации (сейчас он совпадает с номером прохода). Поэтому можно лишь поменять порядок следования комбинаций, но не их состав. Т.е. в данном случае было бы что-то вроде SwapPasses(long index1, long index2).
Возможно, и так. Сейчас на порядок можно еще как-то влиять через Swap input-строк в исходнике советника.
Возможно, и так. Сейчас на порядок можно еще как-то влиять через Swap input-строк в исходнике советника.
Это же убивает алгоритм оптимизации - все равно что оптимизировать в случайном направлении.
Это же убивает алгоритм оптимизации - все равно что оптимизировать в случайном направлении.
Речь про полный перебор в первую очередь.
Постепенно осваиваю ООП и встретился с одной неочевидной вещью.
Есть класс А, полями которого являются объекты другого класса В.
в классе А вызывается константный метод, возвращающий объект класса В.
После чего вызывается метод класса В, стирающий параметры полученного объекта.
Выглядит это так (пример упрощен, писался в браузере):
В результате получается, что Reset() не срабатывает, т.е. поля m_member не очищаются.
Вопрос: не должен ли компилятор на этапе сборки сообщать (ошибку/предупреждение), что вызывается неконстантный метод для константного объекта (или что-то в этом духе)?
Вопрос: не должен ли компилятор на этапе сборки сообщать (ошибку/предупреждение), что вызывается неконстантный метод для константного объекта (или что-то в этом духе)?
Возможно, причина в вызове неявного конструктора копирования в результате Reset вызывается для временного объекта.
Возможно, причина в вызове неявного конструктора копирования в результате Reset вызывается для временного объекта.
Постепенно осваиваю ООП и встретился с одной неочевидной вещью.
Есть класс А, полями которого являются объекты другого класса В.
в классе А вызывается константный метод, возвращающий объект класса В.
После чего вызывается метод класса В, стирающий параметры полученного объекта.
Выглядит это так (пример упрощен, писался в браузере):
В результате получается, что Reset() не срабатывает, т.е. поля m_member не очищаются.
Вопрос: не должен ли компилятор на этапе сборки сообщать (ошибку/предупреждение), что вызывается неконстантный метод для константного объекта (или что-то в этом духе)?