Как организовать взаимодействие C#(Unity) с библиотекой на C++ в случае, когда на стороне C++ нужно сохранять состояние?
Пытаюсь решить задачу, в которой нужно вызывать из кода в Unity функцию из C++, использующую библиотеку dlib для трекинга лица на картинке (сам кейс - юнити отдает кадр с вебкамеры в c++ а обратно приходит трекинговая информация)
Со стороны c++ при вызове функции создается объект predictor который и обрабатывает кадр и проблема какраз в этом объекте.
Объект predictor создается долго и если создавать такой объект при каждом вызове функции - будет слишком большая задержка.
Хотелось бы, чтобы объект создался один раз, после чего хранился в памяти до зовершения выполнения программы на юнити.
Я пока не понимаю даже в какую сторону копать, чтобы решить данную задачу
Через tcp или udp используя какой-либо порт и localhost. Это - самое простое. Придумать быстренько формат передачи, сериализацию и десериализацию сообщений + формат сообщений и все. Также, можно через базу или фай общаться.
нашел такой ответ на вопрос о том, как удобно организовать взаимодействие C# и C++. Только не понимаю сработает ли в моем случае, в том числе, учитывая необходимость кроссплатформенности
Это похоже на какой-то отвратительный костыль (( Что за dlb, у нее есть внятная дока или исходники? Если эта dlb по странной причуде сама не хранит созданный предиктор, должен, по крайней мере, быть доступ к этому объекту, и перегруженные функции, принимающие такой объект (чтоб его можно было между вызовами хранить "снаружи")... Но это все выглядит невероятно странно и указывает на одно из двух: либо эта dlb говнокодовый примерчик, не пригодный для использования в данном юзкейсе, либо ее нужно таки правильно готовить ))
соглашусь с pi314 .что за библиотека/плагин у вас?
вы пробовали уже в деле? точно каждый раз создается объект..?
если библиотека так работает и у вас нет исходников - миритесь с этим.
все верно, речь о библиотеке dlib. символы слились и не увидел пропуск буквы
pi314, а как вобще может быть так, что обьект хранится между вызовами?
а если хранить снаружи - то тоже как это делается
я думаю можно забыть о том, какая библиотека используется, она была просто для задания контекста
вот примерно так по сути выглядит сейчас библиотека
как реорганизовать все это дело так, чтобы не нужно было создавать my_object при каждом вызове функции?
nklyuchnikovspb, Ну, я не разбирался конкретно с этой dlib, сейчас некогда. Но если речь о приведенном псевдопримере, то принцип предельно прост. Переменную my_object нужно вынести из тела метода в члены класса и сделать ленивую инициализацию. Иначе она действительно освобождается, как только поток покидает метод, и ее приходится всякий раз пересоздавать. Если экземпляр класса не уничтожается, то и созданный объект будет жить между вызовами.
Но, во-первых, если такое использование действительно возможно (повторяю, я не смотрел, что это за предиктор и т.д.) то разработчики библиотеки (а она, на первый взгляд, выглядит довольно ванильненько) наверняка позаботились о том, чтоб сделать соотв. метод в API, который это делает сам. А если не сделали, это может означать, что предиктор таки НУЖНО создавать всякий раз заново... словом, это уже все - спекуляции. Нужно разбираться с самой библиотекой.
А по второму варианту, как хранить "снаружи" (хотя это и очень странно, и антипаттерн и т.д.) - метод должен принимать параметром CustomClass, а результат возвращать не как bool, а как какую-нибудь обертку, в которой содержится и результат, и созданный (или просто заюзанный, от чего он, возможно, изменил внутренние состояния) объект CustomClass. Но, повторюсь - так никогда не делайте. За такое разработчиков API подкарауливают в темных переулках и проводят с ними воспитательную беседу на тему SOLID :)
pi314, пока рандомно перебирал варианты таки попробовал вынести инициализацию объекта за пределы функции и объект у меня действительно жил между вызовами метода. но интуитивно казалось что это не должно было сработать.