Я видел эту ссылку, но мне не нужно снимать все заявки, мне нужно снять именно конкретную заявку и ловить по ней события. И благодаря помощи участников форума проблему мне удалось решить.
Знаете, а Вы, скорее всего, правы. Я делаю преобразование с помощью lua_tonumber, а оказывается, что начиная с версии 5.3 lua_Integer - это 64-битный целый тип и можно использовать lua_tointeger. Большое спасибо за помощь, коллективный разум - это сила )
У меня C++, преобразование идет напрямую из Lua Number в uint64_t, а потом уже пишется в лог. По всей видимости, дело действительно в ошибках преобразования из double в uint64_t, судя по https://www.lua.org/pil/2.3.html Если это так, то возникает резонный вопрос к разработчикам - собираются ли они это исправлять и когда. Учитывая, что Lua не имеет целочисленных типов, а биржа транслирует значения за пределами значений double, тут видится два варианта: или разбивать число на две части и передавать в двух полях, или сделать просто строковое поле.
paluke написал: Проверил у себя. На quik 10.1 order_num в OnTransReply имеет тип integer, и номер там без искажений, совпадает с тем что в result_msg. Автор, а брокер у вас какой?
БКС. Проверял на разных версиях, везде одно и то же.
nikolz написал: ваш пример не корректный в нем есть неявный формат печати. Вы уверены что он 64 битный?
Если вопрос ко мне, то да, все значения 64-битные. К тому же, если бы имел место некорректный формат печати, то он был бы некорректен во всех случаях. Но это, как Вы можете видеть, не так.
Спасибо, но это не тот случай. Попытки отправить по нескольку раз не увенчиваются успехом. А вот при подстановке значения из result_msg заявки прекрасно снимаются, собственно, что и следовало ожидать, так как они всегда совпадают со сначением из таблицы заявок. Пока мне пришлось закостылить регулярку и вытаскивать этот номер из result_msg, но согласитесь, что этот способ так себе решение. Все же хотелось услышать мнение кого-нибудь из разработчиков по данному вопросу.
nikolz написал: В OnTransReply может и не быть order_num, так как это ответ сервера брокера на обработку транзакции. Первый раз этот ответ приходит раньше, чем ответ с сервера биржи.
Действительно, Ваш ответ можно было бы принять, но есть нюанс. В поле result_msg номер заявки присутствует, и он всегда верный. Так что проблема явно на стороне квика, уж не знаю там, сервера или клиента. В моем первом сообщении Вы можете увидеть оба случая, когда номера совпадают и когда нет.
В колбеке OnOrder тот же самый order_num, что и в OnTransReply, поэтому его для снятия заявки использовать не получится. А вот брать из таблицы действительно можно, только выглядит это очень уж коряво. И вопрос остается: почему в OnTransReply order_num не совпадает с тем, который в таблице заявок. И еще более удивительно, что иногда они все-таки совпадают. А вот для фондовой секции они совпадают всегда и я спокойно могу использовать order_num из данных, приходящих в OnTransReply.
Обнаружил странное поведение при выставлении заявок на FORTS. Поле order_num, приходящее в колбеке OnTransReply, часто не совпадает со значением в таблице заявок квика, из-за этого не удается программно снять заявку. Тем не менее, бывают редкие случаи, когда эти значения совпадают, и тогда заявки снимаются. При этом обнаружил, что в поле result_msg номер заявки всегда верный. Вот реальные примеры совпадающих номеров и несовпадающих:
SG написал: У вас переполнение типа int. Номера заявок и сделок - это 64-битные целые числа.
SG прав...
ошибка в строчке:
Код
int N = lua_tonumber(L, - 1 );
добавлю только, что судя по определению:
Код
typedef double lua_Number;
lua_Number lua_tonumber (lua_State * L, int index);
произошло преобразование значения типа double превышающего максимально возможное значение типа int, в результате чего было получено значение INT_MIN из <climits> (limits.h)
Код
# define INT_MIN ( - 2147483647 - 1 ) / * minimum (signed) int value * /
Тем не менее, должен заметить, что проблема до конца не решается. Судя по официальной информации, диапазон поддерживаемых целых чисел ограничен 100 000 000 000 000. https://www.lua.org/pil/2.3.html
К сожалению, не нашел, где у вас баг-трекер, поэтому пишу сюда.
Я разрабатываю коннектор для алгоритмической торговли через интерфейс C++ - Lua. В lua скрипте только лишь загружается библиотека, весь остальной функционал реализован на C++. Выяснилось, что в момент вызова функции getSecurityInfo() в случае, если у терминала нет информации по запрашиваемой бумаге, он возвращает данные по бумаге, по которой у него был в последный раз удачный вызов. Если же до этого не было вызовов данной функции, терминал прекращает работу скрипта с сообщении о необработанном исключении. Могу предположить, что в этот момент в самом терминале происходит чтение неинициализированной памяти или нечто в этом роде.