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



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

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

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

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

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

Про валуе типы я подправил. А вот то, что полями могут быть экземпляры классов, как раз и говорит о деревьях.
Так как полей объектов тоже могут быть поля объекты.
EP>

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

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

Подсчет ссыло врапера не спасает, от того, что тебе нужно либо считать ссылки на объект, либо перед удалением искать ссылки во враперах

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

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

То есть в С++ все классы реализуют IUnknown с автоматическим AddRef/Release?
Такого даже в Delphi нет.