История изменений
Исправление rumgot, (текущая версия) :
Возможно для тебя, как разработчика привычней думать на более высоком уровне абстракции и Kotlin (наверное и Java) это хорошо позволяет делать. И в принципе честь и хвала за это. И поэтому в обсуждении в данном случае Qt (да собственно пожалуй вообще C/C++-ой инфроструктуры) ты приводишь аргументы в смысле оценки того, что уровень абстракции здесь гораздо ниже чем в Kotlin/Java. Но тут уж ничего не поделаешь: да C/C++ состоят из функций/калбэков/указателей и т.п. Это цена того, что эти языки стоят на лестнице абстраций ближе к ассемблеру чем Kotlin/Java.
А без такого адаптетра будет окостыливание кода, потому что придется inPlace работать с библиотекой создавая callback hell. Короче говоря пока мы работаем внутри инфраструктуры qt у нас все замечательно, но как только мы за нее выходит, начинается жесть.
Ну тут варианты есть. Например в текущем проекте мы используем Qt, PyTorch, OpenCV и еще несколько библиотек рангом поменьше. Так вот рулит конечно всем Qt. В основном все операции выполняются в слотах Qt. Некоторые затратные операции выполняются в отдельных потоках, организованных опять же через функционал Qt. Данные между потоками гоняются либо посредством Qt-шных сигналов/слотов (при этом типы могут быть отличные от Qt-шных) либо посредством QFuture (опять же типы могут быть не исключительно Qt-шные). Собственно никаких других калбэков кроме Qt-слотов не использовали.
Исходная версия rumgot, :
Возможно для тебя, как разработчика привычней думать на более высоком уровне абстракции и Kotlin (наверное и Java) это хорошо позволяет делать. И в принципе честь и хвала за это. И поэтому в обсуждении в данном случае Qt (да собственно пожалуй вообще C/C++-ой инфроструктуры) ты приводишь аргументы в смысле оценки того, что уровень абстракции здесь гораздо ниже чем в Kotlin/Java. Но тут уж ничего не поделаешь: да C/C++ состоят из функций/калбэков/указателей и т.п. Это цена того, что эти языки стоят на лестнице абстраций ближе к ассемблеру чем Kotlin/Java.
А без такого адаптетра будет окостыливание кода, потому что придется inPlace работать с библиотекой создавая callback hell. Короче говоря пока мы работаем внутри инфраструктуры qt у нас все замечательно, но как только мы за нее выходит, начинается жесть.
Ну тут варианты есть. Например в текущем проекте мы используем Qt, PyTorch, OpenCV и еще несколько библиотек рангом поменьше. Так вот рулит конечно всем Qt. В основном все операции выполняются в слотах Qt. Некоторые затратные операции выполняются в отдельных потоках, организованных опять же через функционал Qt. Данные между потоками гоняются либо посредством Qt-шных сигналов/слотов (при этом типы могут быть отличные от Qt-шных) либо посредством QFuture (опять же типы могут быть не исключительно Qt-шные).