Сразу признаюсь что с poco не работал и не знал о существовании данного фреймворка.
Мы не старались искать готовые решения т.к. у нас своя среда: корутины на базе boost, свои мьютексы и другие примитивы синхронизации с которыми скорее всего не получилось бы подружить решения предоставляющие concurrency в том или ином виде из коробки, коим насколько я понимаю и является данный фреймворк.
На самом деле мой коллега исследовал вариант с Lua. Он сделал бенчмарки и сравнил LuaJIT с V8. В итоге получилось что с кэшированием контекстов с ростом сложности скрипта V8 начинает выигрывать, но его сложнее готовить чем Lua, тут не поспоришь.
Но у V8 больше возможностей (тот же Wasm), JavaScript более распространен и у руководства не было желания начинать поддерживать еще одну технологию, решающую по сути ту же самую задачу.
Насколько я понял из прочитанного по вашей ссылке, там используется внешний генератор исходного кода, так что наверняка лучше, ведь возможностей для анализа данных там больше. Но с другой стороны чтобы мой код работал достаточно только компилятора c++
Возможно ваш подход и лучше. Я редко использую потоки, не подумал о них. Я не считаю что мое решение самое удобное. Скажем так: удобнее с ним чем без него. SerializedSize нужен если в списке аргументов есть экземпляр класса, производный от самого AbstractSaveData. Таких вложений может быть сколь угодно, я посчитал эту возможность полезной.
Спасибо за лестный комментарий :)
Сразу признаюсь что с poco не работал и не знал о существовании данного фреймворка.
Мы не старались искать готовые решения т.к. у нас своя среда: корутины на базе boost, свои мьютексы и другие примитивы синхронизации с которыми скорее всего не получилось бы подружить решения предоставляющие concurrency в том или ином виде из коробки, коим насколько я понимаю и является данный фреймворк.
На самом деле мой коллега исследовал вариант с Lua. Он сделал бенчмарки и сравнил LuaJIT с V8. В итоге получилось что с кэшированием контекстов с ростом сложности скрипта V8 начинает выигрывать, но его сложнее готовить чем Lua, тут не поспоришь.
Но у V8 больше возможностей (тот же Wasm), JavaScript более распространен и у руководства не было желания начинать поддерживать еще одну технологию, решающую по сути ту же самую задачу.
В итоге выбор пал на V8.