Обсуждение статьи "Универсальный торговый эксперт: работа с отложенными ордерами и поддержка хеджинга (часть 5)" - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Предвзятость в отношении const методов. Становление меня как программиста было связано с C# - а там его нет, т.к. ограничение накладываемое модификатором не эффективно.
По наивности думал, что этот модификатор подсказывает еще и компилятору, где можно создать более оптимальный нативный код при компиляции...
Сам использую для самоконтроля.
Основное время в тестере стратегий тратиться на работу его инфраструктуры (прокрутка баров, эмуляция торгового окружения и пр.) На сам код эксперта тратиться гораздо меньше времени.
С другой стороны профилирование показало, что основными ресурсоемкими методами CSTartegy являются методы BuyInit, SellInit, BuySupport и SellSupport - т.е. именно сама логика эксперта непосредственно. Все остальные обвязки успешно компилируются в плоский код оптимальным образом, либо просто вырезаются, если не используются. Поэтому высокоуровневое ООП программирование оправдано.
Замечу, что в более менее сложных экспертах, насчитывающих многие правила и имеющую тяжелую инфраструктуру, программирование в изначально плоском виде (без функций и ООП) приведет к неизбежным ошибкам программиста, и как следствие производительность такого эксперта будет даже меньше чем с ООП. Времена ассемблера прошли. Компилятор уже давно победил человека в определенных областях оптимизации. Человеку осталось задавать изначально грамотную и масштабируемую архитектуру с минимальным количеством интерфейсов и хорошей управляемостью.
По наивности думал, что этот модификатор подсказывает еще и компилятору, где можно создать более оптимальный нативный код при компиляции...
Сам использую для самоконтроля.
Ногами и руками за ООП. Лишь бы только костыльные решения за ним не прятались, как с мультисимвольным OnTick. Который официально разработчики считают не костыльным решением.
Здесь к сожалению на пользовательском уровне ничего не сделаешь. И хотя OnTick в CStrtategy мультивалютный, его мультивалютность тоже эмулируется через костыли. Просто при каждом поступающем событии запрашивается тик другого инструмента, и если он изменился, генерируется новое событие OnTick для этого инструмента. На ФОРТС кстати, CStrategy предоставляет истино мультивалютный OnTick, благодаря событию OnBookEvent. Правда опять-таки при работе в тестере - это эмуляция.
Еще как вариант, снабдить CStrategy индикатором-ресурсом. При запуске CStrategy запускает экземпляр этого индикатора на нужном символе и получает от него событие прихода нового тика. Затем оно конвертируется в OnTick CStrategy. Т.е. классический костыльный вариант, но вся реализация мастерски скрывается за кулисами, и любая стратегия работает унифицированным способом, не зная, как эти тики были получены.
Здесь к сожалению на пользовательском уровне ничего не сделаешь. И хотя OnTick в CStrtategy мультивалютный, его мультивалютность тоже эмулируется через костыли. Просто при каждом поступающем событии запрашивается тик другого инструмента, и если он изменился, генерируется новое событие OnTick для этого инструмента. На ФОРТС кстати, CStrategy предоставляет истино мультивалютный OnTick, благодаря событию OnBookEvent. Правда опять-таки при работе в тестере - это эмуляция.
К сожалению, такой подход пропускает тики.
Еще как вариант, снабдить CStrategy индикатором-ресурсом. При запуске CStrategy запускает экземпляр этого индикатора на нужном символе и получает от него событие прихода нового тика. Затем оно конвертируется в OnTick CStrategy. Т.е. классический костыльный вариант, но вся реализация мастерски скрывается за кулисами, и любая стратегия работает унифицированным способом, не зная, как эти тики были получены.
К сожалению, такой подход пропускает тики.
Да, этот вариант и одобрен разработчиками. Но, ИМХО, видится жутко костыльным, если учесть, как ресурсы оптимизированного тестера тратятся на простейшую для других платформ задачу. ООП - безусловно, прячет костыль мастерски.Читал по диагонали, очень полезные статьи с трудом осиливаю - может что пропустил, мне вот отложенники интересны, но в импульсе многих данных не хватает, ткните пальцем где взять, плиз... или их самому нужно вводить???
Читал по диагонали, очень полезные статьи с трудом осиливаю - может что пропустил, мне вот отложенники интересны, но в импульсе многих данных не хватает, ткните пальцем где взять, плиз... или их самому нужно вводить???
Если Вам что-либо не понятно, Вы можете задать вопросы в этой ветке.