Ошибки, баги, вопросы - страница 2744
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Ошибка:
Спасибо за сообщение.
Исправлено.
Вопрос по оптимизации. В Тестере на каждом тике нужно получить тик для дальнейшей работы. Делаю это так.
Понятно, что этот вариант будет медленнее:
Но еще тормозит SymbolInfoTick, потому что string-параметр передается не по ссылке.
Возможно ли иметь штатные SymbolInfo*-перегрузки, где string передается по ссылке?
А лучше, конечно, иметь
В Оптимизаторе эти функции вызываются десятки миллиардов раз.
Вы предлагаете добавить функцию GetNextEvent ?
Не совсем, скорее бы назвал данную функцию как HandleNextEvent, возможная сигнатура:
bool HandleNextEvent (ENUM_EVENT_TYPE);
При вызове, аналогично GetNextEvent, проверяет наличие указанного ENUM_EVENT_TYPE в очереди,
и при наличии данного события, автоматически передает управление на пользовательский код соответствующего обработчика (OnChartEvent, OnTrade, OnTradeTransaction, ... (спасибо fxsaberза дополнение)).
Возвращает true, если в очереди было событие, в ином случаи - false.
Возможен вариант использования:
Вопрос по оптимизации. В Тестере на каждом тике нужно получить тик для дальнейшей работы. Делаю это так.
Понятно, что этот вариант будет медленнее.
А вы проверяли данное утверждение на практике? Просто может оказаться все наоборот.
MqlTick состоит из примитивных типов данных, которые не инициализируются.
Соответственно, времени на выделение вообще не тратиться, так как это та же операция "sub esp", просто разного размера.
В результате bottleneck может вообще оказаться на стороне кеша процессора для операции чтение значения из памяти.
В общем нужно тестить ))
при наличии данного события, автоматически передает управление на пользовательский код соответствующего обработчика
Возможен вариант использования:
Очень красивое и полезное решение!
А вы проверяли данное утверждение на практике? Просто может оказаться все наоборот.
Теоретизирую здесь. Не проверял. Но передача по ссылке string видится целесообразной.
Возможен вариант использования:
что-то вы дичь какую-то предлагаете.
судя по сигнатуре и вашему описанию, терминал должен по функции вызвать обработку следующего события, а затем вернуть управление в программу в точку вызова handlenextevent?
а если во время обработки опять будет вызов handlenextevent?
а что случается в события которые не попадают под фильтр в параметрах? пропускаются? меняют очередность?
у скриптов вообще нету очереди событий, зачем ее добавлять на костылях если есть советники и индикаторы?
1) что-то вы дичь какую-то предлагаете.
2) судя по сигнатуре и вашему описанию, терминал должен по функции вызвать обработку следующего события, а затем вернуть управление в программу в точку вызова handlenextevent?
3) а если во время обработки опять будет вызов handlenextevent?
4) а что случается в события которые не попадают под фильтр в параметрах? пропускаются? меняют очередность?
1) Мое дело предложить, а дичь ли это, или нет - решать не вам, а разработчикам, им чуть-чуть виднее...
2) Все верно. Если меня интересует обработка конкретного события, а не всех имеющихся в системе, было бы не плохо предоставить возможность обработать только данный тип событий, оставив обработку остальных событий в обычном режиме.
3) Если во время обработки опять будет вызов HandleNextEvent - вызвать и обработать. Единственное что может быть - это переполнение стека, но это проблема пользователя и его кода, а не разработчиков.
4) События, которые не попадают под фильтр, остаются в той же последовательности и будут вызваны, когда пользователь вернет управление в систему, как обычно.
у скриптов вообще нету очереди событий, зачем ее добавлять на костылях если есть советники и индикаторы?
Здесь пример скрипта, который асинхронно открывает и закрывает свои позиции/ордера.
1) Мое дело предложить, а дичь ли это, или нет - решать не вам, а разработчикам, им чуть-чуть виднее...
Если предлагать что-то, что легче реализуется, больше шанс реализации. убрал свой вариант, потому что он практически ничего не дает.