Здравствуйте, Serginio1, Вы писали:

EP>>Это исходный класс что-ли предварительное описание?
S>Ну вообще то да. Или у вас все с открытыми кодами?

Для этого достаточно заголовков (.h/.hpp). Или ты опять предлагаешь враппить произвольные бинарники?

S>Swig делает в итоге делает предварительное описание.

Он генерирует необходимый клей.

S>>>>>Как ваш описатель врапера разберется с зоопарком менеджеров памяти?
EP>>>>Каким зоопарком? Ты о чём?
S>>> То есть у вас как в Delphi один менеждер памяти?
EP>>Не один, и здесь в этом нет проблемы. COM объекты создаются и удаляются на одной стороне.
S> Это когда это такое было?

Всегда.

S>Вся прелесть COM в том, что используется единый менеджер памяти.
S>Строки, массивы могут создаваться на стороне клиента и передаваться в объект. Да и объекты могут создаваться в разных DLL.
S>Еще раз все объекты должны поддерживать подсчет ссылок.

Создание и удаление объекта происходит на одной стороне. Создание в CreateInstance, удаление грубо говоря в Release. Оба метода предоставляются одним и тем же лицом, и работают с одним и тем же менеджером памяти — с тем который определит автор этих методов.
На стороне клиента объект нигде в явном виде не создаётся и не удаляется, грубо говоря нет никаких new и delete.

S>>>Все классы поддерживают подсчет ссылок?
EP>>Это всё прекрасно реализуется неинтрузивно.
EP>>Нет подсчёта ссылок:
EP>>

EP>>struct Widget
EP>>{
EP>>    Data x;
EP>>};
EP>>

Легким движением руки подсчёт ссылок появляется:
EP>>

EP>>shared_ptr<Widget> ref_counted_widget;
EP>>

S>Ну вот у тебя есть две структуры. Кто и когда будет удалять объекты находящихся в полях структуры.

Они удалятся автоматически вместе с аггрегирующей их структурой.

S>По сути тебе нужно, что бы все классы поддерживали подсче ссылок.

Зачем все?

Здравствуйте, Serginio1, Вы писали:

EP>>Это исходный класс что-ли предварительное описание?
S>Ну вообще то да. Или у вас все с открытыми кодами?

Для этого достаточно заголовков (.h/.hpp). Или ты опять предлагаешь враппить произвольные бинарники?

S>Swig делает в итоге делает предварительное описание.

Он генерирует необходимый клей.

S>>>>>Как ваш описатель врапера разберется с зоопарком менеджеров памяти?
EP>>>>Каким зоопарком? Ты о чём?
S>>> То есть у вас как в Delphi один менеждер памяти?
EP>>Не один, и здесь в этом нет проблемы. COM объекты создаются и удаляются на одной стороне.
S> Это когда это такое было?

Всегда.

S>Вся прелесть COM в том, что используется единый менеджер памяти.
S>Строки, массивы могут создаваться на стороне клиента и передаваться в объект. Да и объекты могут создаваться в разных DLL.
S>Еще раз все объекты должны поддерживать подсчет ссылок.

Создание и удаление объекта происходит на одной стороне. Создание в CreateInstance, удаление грубо говоря в Release. Оба метода предоставляются одним и тем же лицом, и работают с одним и тем же менеджером памяти — с тем который определит автор этих методов (например автор соответствующей DLL).
На стороне клиента объект нигде в явном виде не создаётся и не удаляется, грубо говоря нет никаких new и delete.

S>>>Все классы поддерживают подсчет ссылок?
EP>>Это всё прекрасно реализуется неинтрузивно.
EP>>Нет подсчёта ссылок:
EP>>

EP>>struct Widget
EP>>{
EP>>    Data x;
EP>>};
EP>>

Легким движением руки подсчёт ссылок появляется:
EP>>

EP>>shared_ptr<Widget> ref_counted_widget;
EP>>

S>Ну вот у тебя есть две структуры. Кто и когда будет удалять объекты находящихся в полях структуры.

Они удалятся автоматически вместе с аггрегирующей их структурой.

S>По сути тебе нужно, что бы все классы поддерживали подсче ссылок.

Зачем все?