Сообщение Re[105]: Java vs C# vs C++ от 12.10.2015 2:24
Изменено 12.10.2015 2:31 Evgeny.Panasyuk
Здравствуйте, 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>>>Ну и конечно твой нелюбимый GC
EP>>Почему нелюбимый? Без проблем использую языки с GC, о чём тебе лично уже пару раз сказал. Я даже как-то делал копирующий GC for fun.
EP>>Да и причём тут GC?
S> А то, что не нужен подсчет ссылок в объекте. GC сам ведет подсчет.
Счётчик должен быть внутри компонента, это базовый интерфейс — IUnknown. То что конкретные клиенты могут вызывать AddRef/Release на основе разных подходов — дело десятое, и не снимает необходимости в вызове этих AddRef/Release
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 можно к любому) полю, свойству
Про деревья нашёл вот тут — то есть правка уже после того как я прочитал и начал отвечать. Ты если делаешь существенные правки — выноси их в отдельные сообщения
Подсчёт ссылок есть у враппера — он предоставляет AddRef/Release, которые должен дёргать клиент в соответствии с протоколом COM.S> Кстати единственный вариант , это когда есть подсчет ссылок. Я так понимаю, что у вас там куча вариантов даже по этой теме
S> Возьмем пример. Например у тебя есть структура с кучей полей объектов этакое дерево с циклическими ссылками
S>И тебе эту структуру нужно передать на сторону клиента. Врапер структуру обернул. Но у структуры то нет подсчета ссылок?
Если запрашивается свойство не примитивного типа — возвращается новый враппер, при этом если у этого свойства в оригинале нет своего подсчёта ссылок, то будет использоваться счётчик агрегирующего объекта.
S>>>Ну и конечно твой нелюбимый GC
EP>>Почему нелюбимый? Без проблем использую языки с GC, о чём тебе лично уже пару раз сказал. Я даже как-то делал копирующий GC for fun.
EP>>Да и причём тут GC?
S> А то, что не нужен подсчет ссылок в объекте. GC сам ведет подсчет.
Счётчик должен быть внутри компонента, это базовый интерфейс — IUnknown. То что конкретные клиенты могут вызывать AddRef/Release на основе разных подходов — дело десятое, и не снимает необходимости в вызове этих AddRef/Release
Re[105]: Java vs C# vs C++
Здравствуйте, 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>>>Ну и конечно твой нелюбимый GC
EP>>Почему нелюбимый? Без проблем использую языки с GC, о чём тебе лично уже пару раз сказал. Я даже как-то делал копирующий GC for fun.
EP>>Да и причём тут GC?
S> А то, что не нужен подсчет ссылок в объекте. GC сам ведет подсчет.
Счётчик должен быть внутри компонента, это базовый интерфейс — IUnknown. То что конкретные клиенты могут вызывать AddRef/Release на основе разных подходов — дело десятое, и не снимает необходимости в вызове этих AddRef/Release
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 можно к любому) полю, свойству
Про деревья нашёл вот тут — то есть правка уже после того как я прочитал и начал отвечать. Ты если делаешь существенные правки — выноси их в отдельные сообщения
Подсчёт ссылок есть у враппера — он предоставляет AddRef/Release, которые должен дёргать клиент в соответствии с протоколом COM.S> Кстати единственный вариант , это когда есть подсчет ссылок. Я так понимаю, что у вас там куча вариантов даже по этой теме
S> Возьмем пример. Например у тебя есть структура с кучей полей объектов этакое дерево с циклическими ссылками
S>И тебе эту структуру нужно передать на сторону клиента. Врапер структуру обернул. Но у структуры то нет подсчета ссылок?
Если например запрашивается свойство не примитивного типа — возвращается новый враппер, при этом если у этого свойства в оригинале нет своего подсчёта ссылок, то будет использоваться счётчик агрегирующего объекта.
S>>>Ну и конечно твой нелюбимый GC
EP>>Почему нелюбимый? Без проблем использую языки с GC, о чём тебе лично уже пару раз сказал. Я даже как-то делал копирующий GC for fun.
EP>>Да и причём тут GC?
S> А то, что не нужен подсчет ссылок в объекте. GC сам ведет подсчет.
Счётчик должен быть внутри компонента, это базовый интерфейс — IUnknown. То что конкретные клиенты могут вызывать AddRef/Release на основе разных подходов — дело десятое, и не снимает необходимости в вызове этих AddRef/Release