Это почему? Шаблон с const не может принимать не-const - это нарушает контракт.
Шаблон он не сам по себе (в отличии от функции) - его задача выполнить замену (по аналогии с #define). Если по итогам замены противоречий нет (а их там нет) то шаблон со своей задачей справился. По крайней мере я пробовал компилировать это в С++ и компилятор не выдавал ошибок или предупреждений
MT5-OrderSend НЕ полностью синхронизирован - с торговым окружением синхронизации нет. Это значит, что показания истории не соответствуют реальному положению вещей.
Ни о каком timeout и речи быть не может. Надежного решения проблемы нет, т.к. вопросами синхронизации приходится заниматься на уровне терминала, а не сервера.
Фактически, MT5-пользователи столкнулись с тем, с чем сталкивались разработчики бриджей на MT4.
Если отправляется OrderSend, то надо ЗАПОМНИТЬ (вот здесь потенциальная уязвимость), что это сделано. Далее не обращать внимание на текущую историю (торговое окружение), пока не придет соответствующее сообщение в OnTrade. Как только оно прийдет, ЗАПОМНЕННОЕ нужно ЗАБЫТЬ.
Когда нет ЗАПОМНЕННЫХ данных, можно доверять истории, как в MT4.
MT4-OrderSend ПОЛНОСТЬЮ синхронизирован.
Интересно - по какой причине так сделано ... Я понимаю, если мудрить с асинхронным OrderSendAsync, то можно обрабатывать и OnTrade и OnTradeTransaction. C OrderSend хотелось бы простого поведения, как в MT4. Вызвал и на выходе получил уже измененные открытые позиции и историю. Есть тонкий момент. Если запомнить текущее состояние в глобальной переменной и ожидание изменения состояния будет достаточно долго и трейдер умудрится успеть изменить параметры эксперта, то глобальные переменные обнулятся и состояние сбросится.
RickD: Интересно - по какой причине так сделано ... Я понимаю, если мудрить с асинхронным OrderSendAsync, то можно обрабатывать и OnTrade и OnTradeTransaction. C OrderSend хотелось бы простого поведения, как в MT4. Вызвал и на выходе получил уже измененные открытые позиции и историю. Есть тонкий момент. Если запомнить текущее состояние в глобальной переменной и ожидание изменения состояния будет достаточно долго и трейдер умудрится успеть изменить параметры эксперта, то глобальные переменные обнулятся и состояние сбросится.
В этом и есть та самая уязвимость, которую можно получить от необходимости упомянутого запоминания.
Ошибка при компиляции
(*) В общем случае в шаблоне (1) вместо T возможна подстановка как A->(2), так и const A->(3).
Это почему? Шаблон с const не может принимать не-const - это нарушает контракт.
В образовательных целях могу предложить задачу: не вводя дополнительных переменных упростить h() так, чтобы f() вызывалась в любом случае единожды
Это почему? Шаблон с const не может принимать не-const - это нарушает контракт.
Кто-нибудь сталкивался с подобной проблемой? "Баг" терминала или мой?
MT5-OrderSend НЕ полностью синхронизирован - с торговым окружением синхронизации нет. Это значит, что показания истории не соответствуют реальному положению вещей.
Ни о каком timeout и речи быть не может. Надежного решения проблемы нет, т.к. вопросами синхронизации приходится заниматься на уровне терминала, а не сервера.
Фактически, MT5-пользователи столкнулись с тем, с чем сталкивались разработчики бриджей на MT4.
Если отправляется OrderSend, то надо ЗАПОМНИТЬ (вот здесь потенциальная уязвимость), что это сделано. Далее не обращать внимание на текущую историю (торговое окружение), пока не придет соответствующее сообщение в OnTrade. Как только оно прийдет, ЗАПОМНЕННОЕ нужно ЗАБЫТЬ.
Когда нет ЗАПОМНЕННЫХ данных, можно доверять истории, как в MT4.
MT4-OrderSend ПОЛНОСТЬЮ синхронизирован.Я понимаю, если мудрить с асинхронным OrderSendAsync, то можно обрабатывать и OnTrade и OnTradeTransaction. C OrderSend хотелось бы простого поведения, как в MT4. Вызвал и на выходе получил уже измененные открытые позиции и историю.
Есть тонкий момент. Если запомнить текущее состояние в глобальной переменной и ожидание изменения состояния будет достаточно долго и трейдер умудрится успеть изменить параметры эксперта, то глобальные переменные обнулятся и состояние сбросится.
Это не совсем упрощение. В исходном варианте MACRO+2*f+g1+g2=5 - у вас: MACRO+2*f+2*g1+2*g2=7.
Интересно - по какой причине так сделано ...
Я понимаю, если мудрить с асинхронным OrderSendAsync, то можно обрабатывать и OnTrade и OnTradeTransaction. C OrderSend хотелось бы простого поведения, как в MT4. Вызвал и на выходе получил уже измененные открытые позиции и историю.
Есть тонкий момент. Если запомнить текущее состояние в глобальной переменной и ожидание изменения состояния будет достаточно долго и трейдер умудрится успеть изменить параметры эксперта, то глобальные переменные обнулятся и состояние сбросится.
А что возвращает GetLastError() ?
ERR_INDICATOR_DATA_NOT_FOUND
4806
Запрошенные данные не найдены
"Хэндл" индикатора получен, а данные "не найдены" при попытке копирования.