Сообщение Re[103]: Java vs C# vs C++ от 12.10.2015 0:09
Изменено 12.10.2015 0:11 Evgeny.Panasyuk
Здравствуйте, Serginio1, Вы писали:
EP>>>>Это исходный класс что-ли предварительное описание?
S>>>Ну вообще то да. Или у вас все с открытыми кодами?
EP>>Для этого достаточно заголовков (.h/.hpp). Или ты опять предлагаешь враппить произвольные бинарники?
S>Я не предлагаю. Я это делаю для нетовских DLL
S>>>Swig делает в итоге делает предварительное описание.
EP>>Он генерирует необходимый клей.
S> Не клей, а прокси класс.
Клей.
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>>>>
S>>>Ну вот у тебя есть две структуры. Кто и когда будет удалять объекты находящихся в полях структуры.
EP>>Они удалятся автоматически вместе с аггрегирующей их структурой.
S> Автоматически когда?
После того как отработает тело деструктора аггрегирующей их структуры.
S>И почему они должны удаляться если на них есть ссылка на клиенте (во врапере)?
А как он к ним получил доступ?
S>Все объекты должны поддерживать подсчет ссылок
Нет, не все.
S>>>По сути тебе нужно, что бы все классы поддерживали подсчет ссылок.
EP>>Зачем все?
S> Плохо читаешь.
Что конкретно я плохо читаю? То что ты там задним числом наредактировал?
S>Есть объект у которого куча полей с объектами. На стороне клиента получили поле через 2 точки.
Каким образом?
S>Создался врапер.
Когда? Где? Кем? И каким образом?
S>Ну и конечно твой нелюбимый GC
Почему нелюбимый? Я даже делал копирующий GC for fun
Да и причём тут GC?
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?
Re[103]: Java vs C# vs C++
Здравствуйте, Serginio1, Вы писали:
EP>>>>Это исходный класс что-ли предварительное описание?
S>>>Ну вообще то да. Или у вас все с открытыми кодами?
EP>>Для этого достаточно заголовков (.h/.hpp). Или ты опять предлагаешь враппить произвольные бинарники?
S>Я не предлагаю. Я это делаю для нетовских DLL
S>>>Swig делает в итоге делает предварительное описание.
EP>>Он генерирует необходимый клей.
S> Не клей, а прокси класс.
Клей.
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>>>>
S>>>Ну вот у тебя есть две структуры. Кто и когда будет удалять объекты находящихся в полях структуры.
EP>>Они удалятся автоматически вместе с аггрегирующей их структурой.
S> Автоматически когда?
После того как отработает тело деструктора аггрегирующей их структуры.
S>И почему они должны удаляться если на них есть ссылка на клиенте (во врапере)?
А как он к ним получил доступ?
S>Все объекты должны поддерживать подсчет ссылок
Нет, не все.
S>>>По сути тебе нужно, что бы все классы поддерживали подсчет ссылок.
EP>>Зачем все?
S> Плохо читаешь.
Что конкретно я плохо читаю? То что ты там задним числом наредактировал?
S>Есть объект у которого куча полей с объектами. На стороне клиента получили поле через 2 точки.
Каким образом?
S>Создался врапер.
Когда? Где? Кем? И каким образом?
S>Ну и конечно твой нелюбимый GC
Почему нелюбимый? Без проблем использую языки с GC, о чём тебе лично уже пару раз сказал. Я даже как-то делал копирующий GC for fun.
Да и причём тут GC?
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, о чём тебе лично уже пару раз сказал. Я даже как-то делал копирующий GC for fun.
Да и причём тут GC?