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


.
S>>>>Вся прелесть COM в том, что используется единый менеджер памяти.
S>>>>Строки, массивы могут создаваться на стороне клиента и передаваться в объект. Да и объекты могут создаваться в разных DLL.
S>>>>Еще раз все объекты должны поддерживать подсчет ссылок.
EP>>>Создание и удаление объекта происходит на одной стороне. Создание в CreateInstance, удаление грубо говоря в Release. Оба метода предоставляются одним и тем же лицом, и работают с одним и тем же менеджером памяти — с тем который определит автор этих методов (например автор соответствующей DLL).
S>> Тогда в объекте должна быть ссылка на свой менеджер памяти и удаление через него.

EP>Она есть. В простейшем виде такая ссылка зашита в самом коде методов CreateInstance и Release.
EP>А нужные методы вызываются правильным выбором vtable ptr, который находится по указателю с которым работает пользователь.

S>>Это же по сути виртуальный деструктор

EP>В обязанности деструктора не входит очистка памяти. Его например можно вызывать без очистки памяти.
EP>Release грубо говоря это виртуальный метод который внутри делает что-то типа if(--counter == 0) delete this;, а уже delete вызывает деструктор (который даже может быть не виртуальным) и очищает память.

Тогда C++ это тормоза. А ты говоришь о скорости.
S>>Если объекты создаются из разных DLL пусть это даже будут копии, то это уже будут разные типы. И при передаче параметра будет вызвано исключение.

EP>Какого параметра?

У класса есть методы, у метода есть параметры, в том числе и out
S>>Кроме того в двух DLL могут быть разные версии класса, что приводит к повреждению памяти.

EP>Из-за чего?
EP>Объекты могут быть разных версий, иметь разные менеджеры памяти, и при этом прекрасно сочетаться друг с другом

А обращаться к несуществующим полям, или массивам меньшей длины?
S>> И при передаче данных из разных DLL это еще и разные враперы.

EP>И что?

А то, что разные версии Swig и соответственно разные поля
S>>>>>>Все классы поддерживают подсчет ссылок?
S>>>>Ну вот у тебя есть две структуры. Кто и когда будет удалять объекты находящихся в полях структуры.
EP>>>Они удалятся автоматически вместе с аггрегирующей их структурой.
S>> Автоматически когда?

EP>После того как отработает тело деструктора аггрегирующей их структуры.

S>>И почему они должны удаляться если на них есть ссылка на клиенте (во врапере)?

EP>А как он к ним получил доступ?
А как ты получаешь доступ к полям, свойствам объекта.

S>>Все объекты должны поддерживать подсчет ссылок

EP>Нет, не все.

S>>>>По сути тебе нужно, что бы все классы поддерживали подсчет ссылок.
EP>>>Зачем все?
S>> Плохо читаешь.

EP>Что конкретно я плохо читаю? То что ты там задним числом наредактировал?
Я тебе уже кучу времени долблю про деревья, и то что у клиента должен быть доступ к любому публичному (в Net можно к любому) полю, свойству

S>>Есть объект у которого куча полей с объектами. На стороне клиента получили поле через 2 точки.

EP>Каким образом?
А как ты достаешь Объект.Поле1.Тратаьа
S>>Создался врапер.

EP>Когда? Где? Кем? И каким образом?

Не знаю, что там твой SWIG нагородил
S>>Ну и конечно твой нелюбимый GC

EP>Почему нелюбимый? Без проблем использую языки с GC, о чём тебе лично уже пару раз сказал. Я даже как-то делал копирующий GC for fun.
EP>Да и причём тут GC?
А то, что не нужен подсчет ссылок в объекте. GC сам ведет подсчет.