Информация об изменениях

Сообщение Re[103]: Java vs C# vs C++ от 12.10.2015 0:09

Изменено 12.10.2015 0:10 Evgeny.Panasyuk

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

EP>>>>Это исходный класс что-ли предварительное описание?

S>>>Ну вообще то да. Или у вас все с открытыми кодами?
EP>>Для этого достаточно заголовков (.h/.hpp). Или ты опять предлагаешь враппить произвольные бинарники?
S>Я не предлагаю. Я это делаю для нетовских DLL
S>>>Swig делает в итоге делает предварительное описание.
EP>>Он генерирует необходимый клей.
S> Не клей, а прокси класс.

Клей.

http://www.swig.org/
SWIG is typically used to parse C/C++ interfaces and generate the 'glue code' required for the above target languages to call into the C/C++ code.


S>>>Вся прелесть COM в том, что используется единый менеджер памяти.

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

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

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


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

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


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

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


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

S> И при передаче данных из разных DLL это еще и разные враперы.


И что?

S>>>>>Все классы поддерживают подсчет ссылок?

EP>>>>Это всё прекрасно реализуется неинтрузивно.
EP>>>>Нет подсчёта ссылок:
EP>>>>
EP>>>>struct Widget
EP>>>>{
EP>>>>    Data x;
EP>>>>};
EP>>>>
Легким движением руки подсчёт ссылок появляется:

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

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

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

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


А как он к ним получил доступ?

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


Нет, не все.

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

EP>>Зачем все?
S> Плохо читаешь.

Что конкретно я плохо читаю? То что ты там задним числом наредактировал?

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


Каким образом?

S>Создался врапер.


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

S>Ну и конечно твой нелюбимый GC


Почему нелюбимый? И причём тут GC?
Здравствуйте, Serginio1, Вы писали:

EP>>>>Это исходный класс что-ли предварительное описание?

S>>>Ну вообще то да. Или у вас все с открытыми кодами?
EP>>Для этого достаточно заголовков (.h/.hpp). Или ты опять предлагаешь враппить произвольные бинарники?
S>Я не предлагаю. Я это делаю для нетовских DLL
S>>>Swig делает в итоге делает предварительное описание.
EP>>Он генерирует необходимый клей.
S> Не клей, а прокси класс.

Клей.

http://www.swig.org/
SWIG is typically used to parse C/C++ interfaces and generate the 'glue code' required for the above target languages to call into the C/C++ code.


S>>>Вся прелесть COM в том, что используется единый менеджер памяти.

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

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

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


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

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


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

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


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

S> И при передаче данных из разных DLL это еще и разные враперы.


И что?

S>>>>>Все классы поддерживают подсчет ссылок?

EP>>>>Это всё прекрасно реализуется неинтрузивно.
EP>>>>Нет подсчёта ссылок:
EP>>>>
EP>>>>struct Widget
EP>>>>{
EP>>>>    Data x;
EP>>>>};
EP>>>>
Легким движением руки подсчёт ссылок появляется:

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

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

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

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


А как он к ним получил доступ?

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


Нет, не все.

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

EP>>Зачем все?
S> Плохо читаешь.

Что конкретно я плохо читаю? То что ты там задним числом наредактировал?

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


Каким образом?

S>Создался врапер.


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

S>Ну и конечно твой нелюбимый GC


Почему нелюбимый? Я даже делал копирующий GC for fun
Да и причём тут GC?