Станислав Макаров

он зависит от большого количества so-библиотек.

У вас два варианта:
1. Использовать статические варианты библиотек вместо динамических (so) - это то, что предлагает Vitaly.
2. Продолжать собирать как сейчас, но научиться собирать нормальные пакеты под нужные вам дистрибутивы, с нормальным описанием зависимостей - тогда системный пакетный менеджер при установке вашего пакета поставит все нужные вам зависимости.

Второй вариант сложнее, но предпочтительнее, т.к. в случае критических уязвимостей в библиотеках их можно будет обновить независимо без обновления вашего приложения. Когда вы линкуете статически, очевидно что уязвимый код в вашем бинарнике можно обновить только пересборкой этого бинарника с новой версией библиотеки, т.е. без вашего участия (если код закрыт) уязвимость не устранить. Критично ли это для вас или нет - решать вам, зависит от важности вашего приложения.

Встал вопрос об оптимизации данного действия, потому как на обновление таблицы уходит минимум 2 минуты.

Ну это известный прикол что по-умолчанию SQlite делает транзакцию на каждый insert. Запустите транзакцию и закоммитьте её один раз и все строки вставятся за секунду максимум.

Вы начали выдумывать какие-то мегаспособы ускорения, не исследовав корень проблемы. А корень в том, что на транзакцию SQLite создаёт файл отката, и когда таки транзакций 40000, это будет столько же операций пересоздания файла. Это просто пздц какая тяжелая операция для файловой системы, и ни процессор ни многопоточность вообще не при чём. Могли бы догадаться сами, т.к. 40000 небольших записей это вообще не объём.

Решение гуглится за 20 секунд и написано в FAQ по SQLite: www.sqlite.org/faq.html#q19

Мне нужно выполнить функцию при удалении объекта, поэтому я переопределил деструктор.

Почему вы решили, что деструктор базового класса, т.е. поведение, которое отработало бы без вашего переопределения, НЕ будет вызван?

cppwhispers.blogspot.ru/2012/11/unicode-and-your-a...

In GCC, on modern systems, the default encoding for char string literals is UTF8.

А чтобы не зависеть от компилятора и среды, курите современную теорию: раз, два.

Обязательно ли использовать С++ для игр?

Ваш вопрос настолько топорно составлен, что даже непонятно как вообще отвечать.

1. Передачу объекта из одной среды в другую не обязательно решать блокировкой (lock) именно того объекта, что существует в "мире" lua.
2. Даже если блокировать lua-объект, почему вы собрались это делать shared_ptr-ом?? Он как-то шарит владение с менеджером памяти lua? Не слышал о такой возможности. Т.е. я не думаю что

Проблема решается через shared_ptr

3. Зачем всё переписывать на использование shared_ptr?? вы хотите начать писать на плюсах как на lua? даже если бы ваши предположения в п.1 и п.2 магическим образом оказались верны, shared_ptr и сборка мусора - сильно разные вещи, не разобравшись ни в одной из них до конца, вы посчитали что это одно и то же потому что оно "похоже".
4.

ведь производительность упадет

не упадёт, точнее вы этого не узнаете т.к. ничего нормального по такой стратегии не напишете.

Пишу игру на c++ и lua.

Вы вообще писали на C++ или сразу пишете на "C++ и Lua"?

можно ли использовать shared_ptr в играх

Можно, в тех местах где это целесообразно. Не думаю что игры сильно отличаются в этом вопросе от других C++ проектов.

и есть ли какие то другие решения передачи объектов между lua и c++?

А что говорить документация используемого вами интерпретатора lua?

Meyers, Scott. Effective modern C++ [42 specific ways to improve your use of C++11 and C++14]
ISBN: 978-1-491-90399-5
https://www.amazon.co.uk/dp/1491903996

Resource Files (Visual Studio) (на русском).
Удобная утилита для просмотра (проверить, что получилось после компиляции и что где по факту легло в ресурсах): Resource Hacker.

std::vector<std::vector<int>> vector_of_vectors;
vector_of_vectors.push_back({ 1,1,1,1,1 });
std::cout << vector_of_vectors << std::endl; // [[1,1,1,1,1]]
vector_of_vectors.push_back({ 1,1,1,1,2 });
std::cout << vector_of_vectors << std::endl; // [[1,1,1,1,1],[1,1,1,1,2]]

https://ideone.com/GIV9dW

проверка "правильности/соответсвия" возвращаемых данных определенными функциями

Это есть модульное тестирование, см. Catch.

проверка на используемую память(сколько используется, было использованно за весь цикл существования приложения)

Погуглите "memory profiler" (например, valgrind.org/docs/manual/ms-manual.html ). Я обычно в Студии профайлю, с автоматизацией этого процесса пока не сталкивался, но думаю возможно.

проверка правильности порядка записи в бд

проверка того что в сеть уходят данные которые ожидаются от программы

Тут вам нужно замокать клиента к бд и сетевой сокет/поток (в зависимости от того как это всё реализовано, без подробностей сложно советовать), и вместо реальной отправки данных/записи в базу делать нужные вам проверки.

Вы не можете вызвать "функции одного потока в другом". Каждый поток должен сам вызвать то, что ему нужно.

Чтобы это реализовать, вы можете, к примеру, организовать циклы обработки сообщений и обмениваться сообщениями между потоками.

Более конкретно ответить можно только зная какими библиотеками и API вы пользуетесь в вашем проекте.

Допустим есть команда профессиональных, финансово-неограниченных, C/C++ программистов, которые предпочитают писать на C++, но были вынуждены выбрать язык C для решения следующих задач....что это за задачи и почему?

1. Низкоуровневые задачи, где нужно иметь минимум абстракции от оборудования. Я лично хоть и не разделяю анти-C++ настроений Линуса, вполне согласен с тем что ядру полезно быть написанным на Си. В C++ есть довольно много абстракций, влияющих на исполнение кода, есть некоторые вещи "под капотом", которые могут быть недопустимы в низкоуровенвом коде.

2. Большие проекты, где сложно форсировать code-style. С++ - это такой язык... Он настолько разнообразен, что прежде чем некая команда сядет писать код, она должна выбрать некоторое ПОДМНОЖЕСТВО языка, и использовать его. Иными словами, Плюсы - это большой ящик с инструментами, и вовсе не обязательно (даже вредно) использовать сразу все. Важно отказываться от каких-либо возможностей или практик, особенно устаревших (а таких в C++ немало, "идиоматический" код на C++03 и C++17 - очень разный). Кто не хочет со всем этим заморачиваться (вспомним опять таки Линух - огромный проект с огромным числом участников) - вполне могут выбрать Си. Ведь можно считать, что выбор языка Си - это выбор только необходимого инструментария из того что предлагается в C++ (только помните что сейчас это всё-таки разные языки).

3. Программирование в сильных ресурсных ограничениях. Например под микроконтроллеры. Хоть в С++ программист "не платит за то чем не пользуется", иногда стандартные реализации различных механизмов недопустимо тяжелы или неэффективны. Например, если у вас очень медленный чип или мало памяти, возможно вы заходите свою собственную реализацию полиморфизма. Какой тогда смысл говорить что вы пишете на C++, если не сможете использовать его механизмы и то, что предлагает компилятор.