Загружай функции, которые создают объекты класса с определенным интерфейсом.

Обёртка очевидное решение.
Мне бы классы...

После компилции программы на С++ не остаётся классов.

Да и, кстати, как ты себе представляешь работу с такими классами? Что они были тебе полезны они должны реализовывать определённые интерфейсы, которые известны твоей программе, для того чтобы ты мог создавать объекты этих классов тебе нужны для каждого класса функция-конструктор (вместо оператора new) и функция-деструктор (уничтожающая объект и освобождающая память, вместо оператора delete).

В Poco есть штука, позволяющая создавать объекты классов, объявленных/реализованных в разделяемой библиотеке. Хотя это как раз и есть та самая обертка libdl.

Дяденька, а у меня другой вопрос, возможно дурацкий, можно?;-)

Вот у меня есть модуль 1, в этом модуле есть набор глобальных переменных (статических полей некоего класса). Вот у меня есть модуль 2, в котором через интерфейс описанный в хидере из 1 я как то 1 юзаю. 2 собран в виде so-шки, это С++ протащенный через SWIG в питон. И есть модуль 3, тоже С++ в питон, в котором я тоже юзаю модуль 1. Теперь я в одном процессе (скрпите питона) импортю 2 и 3 - как бы так сделать, что бы набор глобальных переменных из 1 был один на всех в рамках процесса?

Я как наивный чукосткий юноша собрал 1 не как объектник а как so-шку (с опцией -shared), прилинковал в 2 и 3 - не помогает, наборы разные.

Пусть есть модуль 1:

// A.hh:
#pragma once

struct A
{
  static int x;
};

// A.cc:
#include "A.hh"

int A::x = 314;

extern "C" void bar()
{
  A::x = 271;
}

и модуль 2:

// B.cc:
#include <iostream>
#include "A.hh"

extern "C" void foo()
{
  std::cout << A::x << std::endl;
}

и программа:

// M.cc:
#include <iostream>
#include <dlfcn.h>

#include "A.hh"

int main()
{
  void* A = dlopen("./A.so", RTLD_NOW bitor RTLD_GLOBAL);
  void* B = dlopen("./B.so", RTLD_NOW);
  void (*foo)() = reinterpret_cast<void (*)()>(dlsym(B, "foo"));
  void (*bar)() = reinterpret_cast<void (*)()>(dlsym(A, "bar"));

  foo();
  bar();
  foo();
}

Собираем и выполняем:

> gcc -shared -o A.so -fPIC A.cc
> gcc -shared -o B.so -fPIC B.cc
> g++ -o M M.cc -ldl
> ./M
314
271

Я правильно понял твою ситуацию?

а еще можно по приколу v8 заэмбеддить, тогда классы можно будет грузить из js-файлов (в теории)

Вообще-то этот функционал (плагины на JS) есть в Qt.

В Poco есть штука...

Спасибо.

а еще можно по приколу v8 заэмбеддить, тогда классы можно будет грузить из js-файлов

А можно заэмбеддить luabind и грузить классы из Lua... но вопрос не об этом.

Вообще-то этот функционал (плагины на JS) есть в Qt.

На Qt то я и оглядываюсь.

Не совсем. Структура модулей такая: http://a-iv.ru/trash/sph-strcuct.pdf Как там в питоне (с какими флагами) импортируются модули я честно говоря затрудняюсь сказать, да и повлиять на это сложно, но вот A.so я цепляю сам. Вопрос - как правильно прицепить A.so (крайне желательно на этапе линковки В.so, C.so а не в коде) что бы статические поля из A были общими для B и C в run.py?

1. A.so надо загуржать с RTLD_GLOBAL

2.

Как там в питоне (с какими флагами) импортируются модули я честно говоря затрудняюсь сказать, да и повлиять на это сложно

> import sys
> print sys.setdlopenflags.__doc__
setdlopenflags(n) -> None

Set the flags that will be used for dlopen() calls. Among other
things, this will enable a lazy resolving of symbols when importing
a module, if called as sys.setdlopenflags(0)
To share symbols across extension modules, call as
sys.setdlopenflags(dl.RTLD_NOW|dl.RTLD_GLOBAL

Это не оно?

> 1. A.so надо загуржать с RTLD_GLOBAL

Я прошу прощение за нубовский вопросы, но можно это сделать при линковке B? Ну типа

g++ -shared B.cpp A.so -o B.so

Это не оно?

Это видимо оно, и оно даже помогает (при загрузке B и C в run.py), спасибо большое! Хотя при линковке B, C вариант был бы более изящный (если это возможно).