Найди Мейл лист по SWIG, спроси там...
Также тебе надо уточнить что куда откуда ты хочешь возвращать

Спасибо, порыскаю. Хотя, честно-говоря, никогда дел с мэйл листами не имел =)
А по поводу уточнить - хороший совет. Не могу представить, как это должно выглядеть. То есть, если разложить по полочкам.
В моей плюсовой библиотеке B есть класс, назовём его MyClass, в этом классе есть метод getRainbow, который возвращает указатель на объект класса из подключённой библиотеки A, скажем LibClass. Вроде всё просто и понятно пока, поехали дальше.
Есть обёртка для библиотеки A - _a она написана совершенно другими людьми. Если я в Python создаю объект класса LibClass, то благодаря этой обёртке могу дёргать его методы, видеть поля.
Тоже понятно.
Если я создаю обёртку _b для своей библиотеки, то в Python я могу из своего метода вернуть указатель на объект LibClass, но это будет не объект из обёртки _a, а просто свиговский какой-то объект, к его методам и полям доступа нет.
Вообще, понятное дело, чего бы это моя обёртка знала о чужой, с какой это радости вообще? В этом-то и вопрос, возможно ли как-то подружить две обёртки, мою и стороннюю. Фух, настрочил, сумбурненько всё-таки...

ну, видится единственный вариант декорировать объект обертки своим классом и делегировать вызовы, но это будет работать при условии, что ты будешь принимать уже существующий LibClass извне и оборачивать его:

struct LibClass {
    virtual void foo() = 0;
...
};
struct MyClass {
         LibClass* getRainbow(LibClass* decorable) {
               struct LibClassDecorator : LibClass {
                        LibClass* decorable;
                        LibClassDecorator(LibClass* decorable) : decorable{decorable} {}
                        virtual void foo() override {
                                decorable->foo();
                        }
               };
               return new LibClassDecorator(decorable);
         }
};

но, это, вроде, вопрос не о С++ получается.

struct LibClass {
    virtual void foo() = 0;
...
};
struct MyClass {
         LibClass* getRainbow(LibClass* decorable) {
               struct LibClassDecorator : LibClass {
                        LibClass* decorable;
                        LibClassDecorator(LibClass* decorable) : decorable{decorable} {}
                        virtual void foo() override {
                                decorable->foo();
                        }
               };
               return new LibClassDecorator(decorable);
         }
};

Хмм, надо разобраться, подумать. Спасибо за совет.

В том-то и дело, вопрос на стыке и для моего уровня сложен.

просто стыковка с Python - это С интерфейс.

есть некий сервис на С++, который состоит из множества частей. Хотелось бы понимать в разные моменты времени, какие части приложения сколько выжрали оперативной памяти. То есть организовать достаточно детализированный профайлинг памяти для приложения.

Сейчас регулярно снимается стастика с аллокатора (jemalloc), но понятное дело, что это говорит только о ситуации для всего приложения.

Есть идеи, как подобное организовать?

Первое, что мне приходит в голову - разным частям приложения раздать разные аллокаторы и зафорсить по крайней мере для начала административно их использование в различных подсистемах приложения. Ну или свой аллокатор с какими-то метками для каждой части приложения, которые при аллоках\деаллоках будет заниматься подсчётом нужной статистики.

Почему не используются готовые утилиты профайлинга - они не дают нужной точности.

Если важно - С++14

Также есть вариант каждую подсистему заставить саму мочь подсчитать занятую память. Аля дергаешь метод GetMemoryConsumption() у каждой подсистемы, а она уже пошла по всем своим контейнерам это дело считать.

Но выглядит отвратительно, конечно же

Ну а что значит подсистемы? Функции занимают место только на стеке, что думаю не так много. Соответственно речь видимо идет о памяти в куче. Как правило, память в куче лежит в контейнерах (map, vector). Соответственно можно посмотреть сколько занимают эти контейнеры, или сняв статистику с аллокатора или просто вызывав size у контейнера

Не всегда тривиально обойти все контейнеры. Думаю реально самый простой способ сделать аллокаторы и трекать память через них

Обычно профайлеры собирают коллстеки на все аллокации/деаллокации, если разрезолвить их символами, можно поматчить по модулям и сделать вьюшки удобные. Можно и руками это сделать. Что значит профайлеры не дают нужной точности?

А почему бы просто не создать некого Owner-а каждому алокатору?

микросервисы? )

подсистема читай как обьект класса с кучей подобьектов

можешь сделать так: основной процесс форкается в несколько частей, каждая из которых использует только какую-то часть

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

но от акторов до микросервисов... 😊

минусы - надо делать кросспроцессные очереди, но по факту на концепцию акторов это не так уж и плохо накладывается

если говорить про семплирующие, то сэмпл может не попасть на отрезок времени, в который произошло что-то важное