Параметры источника данных в колбэке
kv-gits opened this issue · 5 comments
Можно ли как-то организовать в с++ подобный код?
self.ds:SetUpdateCallback(function(...) updcallback(self, class, security, startpos,...) end)
Чтобы в колбэке была возможность получить параметры источника данных.
К сожалению, я не понял задачу. Функции коллбеков, назначенные статично, статичны, то есть, если они объявлялись через соответствующие макросы luacpp, они будут привязаны к указанной в макросе соответствующей функции С. Если нужно некое условное исполнение кода внутри такого коллбека, то его следует делать внутри этой функции.
В lua это называется closure. Это позволяет динамически создавать датасорсы и получать в колбэке их параметры. Хочется просто универсальный интерфейс создания датасорсов через параметры, вместо того, чтобы в коде прописывать колбэк для каждого инструмента.
Если вы хотите создавать функции lua динамически и наначать им соответстующую функцию С, то дела обстоят как я написал выше. Сейчас коллбек назначается так:
qluacpp/src/qlua/structs/datasource.hpp
Line 130 in 34e658f
То есть функцию надо называть по имени. Поэтому варианта два: либо делать то что делает эта функция внутри и назначать колбеку обработчик, который не доступен в C++ через luacpp (замыканию). В этом случае можно писать код в любом Lua-виде в качестве обработчиков. Либо использовать эту функцию, назначать один обработчик, а диспетчинг делать на C++ внутри этого.
диспетчинг делать на C++ внутри этого.
Смысл в том, что без замыкания не получится сделать универсальный диспетчер, потому что в колбэк не поступают данные о самом источнике данных, только его изменения. Придется для каждого источника писать отдельный колбэк, а если их 50-100 или вообще заранее не известно?
Вот тут подробнее описан механизм.
http://www.bot4sale.ru/blog-menu/qlua/379-1-collback-for-al-ds.html
Имхо, его не хватает в qluacpp и придется часть кода опять на lua делать.
В принципе, можно по другому подойти к вопросу - не делать колбэк к источнику вообще, а диспетчер прописать в глобальном колбэке onAllTrades. Чуть просадка в скорости будет, но тоже относительно чистое решение.
Все что касается DataSource - это работа со свечками Quik, вторичными данными. Поддержка вторичных данных в Qluacpp - скорее "для красоты". Если не писать что-то, что должно передавать именно вторичные данные Quik, например скрипт рисующий свечки точно так же, как это делает Quik, никакого смысла их использовать нет. И тем более нет преимуществ перед работой с первичными данными. Использование onAllTrades естественно предпочтительнее, также см. #24 (comment)