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

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

S> Тогда C++ это тормоза. А ты говоришь о скорости.

Как ты пришёл к такому выводу?

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

Если у параметра тип который даёт единый ABI интерфейс для разных версий — то никаких проблем не будет.

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

Проблемы будут есть вызывать методы одного класса на объекте другого. Если методы виртуальные и интерфейсы не поменялись, или вообще динамические а-ля Invoke — то проблемы не будет.
Если же у тебя в голове какой-то use-case, в котором метод одного класса вызывается на объекте другого класса — то так и опиши его, я мысли читать не умею.

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

Про деревья нашёл вот тут — то есть правка уже после того как я прочитал и начал отвечать. Ты если делаешь существенные правки — выноси их в отдельные сообщения

S> Кстати единственный вариант , это когда есть подсчет ссылок. Я так понимаю, что у вас там куча вариантов даже по этой теме
S> Возьмем пример. Например у тебя есть структура с кучей полей объектов этакое дерево с циклическими ссылками
S>И тебе эту структуру нужно передать на сторону клиента. Врапер структуру обернул. Но у структуры то нет подсчета ссылок?

Подсчёт ссылок есть у враппера — он предоставляет AddRef/Release, которые должен дёргать клиент в соответствии с протоколом COM.
Если например запрашивается свойство не примитивного типа — возвращается новый враппер, при этом если у этого свойства в оригинале нет своего подсчёта ссылок, то будет использоваться счётчик агрегирующего объекта.

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

Счётчик должен быть внутри компонента, это базовый интерфейс — IUnknown. То что конкретные клиенты могут вызывать AddRef/Release на основе разных подходов — дело десятое, и не снимает необходимости в вызове этих AddRef/Release