Ошибки, баги, вопросы - страница 2744
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
А вы проверяли данное утверждение на практике? Просто может оказаться все наоборот.
Теоретизирую здесь. Не проверял. Но передача по ссылке string видится целесообразной.
Возможен вариант использования:
что-то вы дичь какую-то предлагаете.
судя по сигнатуре и вашему описанию, терминал должен по функции вызвать обработку следующего события, а затем вернуть управление в программу в точку вызова handlenextevent?
а если во время обработки опять будет вызов handlenextevent?
а что случается в события которые не попадают под фильтр в параметрах? пропускаются? меняют очередность?
у скриптов вообще нету очереди событий, зачем ее добавлять на костылях если есть советники и индикаторы?
1) что-то вы дичь какую-то предлагаете.
2) судя по сигнатуре и вашему описанию, терминал должен по функции вызвать обработку следующего события, а затем вернуть управление в программу в точку вызова handlenextevent?
3) а если во время обработки опять будет вызов handlenextevent?
4) а что случается в события которые не попадают под фильтр в параметрах? пропускаются? меняют очередность?
1) Мое дело предложить, а дичь ли это, или нет - решать не вам, а разработчикам, им чуть-чуть виднее...
2) Все верно. Если меня интересует обработка конкретного события, а не всех имеющихся в системе, было бы не плохо предоставить возможность обработать только данный тип событий, оставив обработку остальных событий в обычном режиме.
3) Если во время обработки опять будет вызов HandleNextEvent - вызвать и обработать. Единственное что может быть - это переполнение стека, но это проблема пользователя и его кода, а не разработчиков.
4) События, которые не попадают под фильтр, остаются в той же последовательности и будут вызваны, когда пользователь вернет управление в систему, как обычно.
у скриптов вообще нету очереди событий, зачем ее добавлять на костылях если есть советники и индикаторы?
Здесь пример скрипта, который асинхронно открывает и закрывает свои позиции/ордера.
1) Мое дело предложить, а дичь ли это, или нет - решать не вам, а разработчикам, им чуть-чуть виднее...
Если предлагать что-то, что легче реализуется, больше шанс реализации. убрал свой вариант, потому что он практически ничего не дает.
Вопрос по оптимизации. В Тестере на каждом тике нужно получить тик для дальнейшей работы. Делаю это так.
Понятно, что этот вариант будет медленнее:
Но еще тормозит SymbolInfoTick, потому что string-параметр передается не по ссылке.
Возможно ли иметь штатные SymbolInfo*-перегрузки, где string передается по ссылке?
А лучше, конечно, иметь
В Оптимизаторе эти функции вызываются десятки миллиардов раз.
вызов функции Symbol() ВСЕГДА разворачивается в доступ к глобальной переменной _Symbol, как и Digits(), Point(), Period(), GetLastError(), IsStopped(), UninitializeReason()
вызов функции Symbol() ВСЕГДА разворачивается в доступ к глобальной переменной _Symbol, как и Digits(), Point(), Period(), GetLastError(), IsStopped(), UninitializeReason()
А передача string по ссылке?
А передача string по ссылке?
Видимо причина в одной из нерешаемых проблем в MQL - передача литерала в качестве параметра по const ref.
Возможно ли иметь штатные SymbolInfo*-перегрузки, где string передается по ссылке?
А как они помогут?
Все равно возвращается(вызывается) 1, а не 2
А передача string по ссылке?
Строка передаётся по ссылке.
Мы уже давно перешли на "copy_on_write строки" -> при копировании одной строки в другую контент не копируется сразу (как это было раньше), увеличивается количество ссылок на буфер строки
Например, количество ссылок увеличивается при передаче строки по значению, в качестве параметра и уменьшается после вызова.
Когда строка меняется, проверятся счётчик ссылок на буфер и если ссылок больше одной, то изменяемая строка "отцепляется" от старого буфера и ей выделяется новый.