Сообщение Re[102]: Java vs C# vs C++ от 11.10.2015 23:32
Изменено 11.10.2015 23:42 Serginio1
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
EP>>>Это исходный класс что-ли предварительное описание?
S>>Ну вообще то да. Или у вас все с открытыми кодами?
EP>Для этого достаточно заголовков (.h/.hpp). Или ты опять предлагаешь враппить произвольные бинарники?
S>>Swig делает в итоге делает предварительное описание.
EP>Он генерирует необходимый клей.
Не клей, а прокси класс.
S>>>>>>Как ваш описатель врапера разберется с зоопарком менеджеров памяти?
EP>>>>>Каким зоопарком? Ты о чём?
S>>>> То есть у вас как в Delphi один менеждер памяти?
EP>>>Не один, и здесь в этом нет проблемы. COM объекты создаются и удаляются на одной стороне.
S>> Это когда это такое было?
EP>Всегда.
S>>Вся прелесть COM в том, что используется единый менеджер памяти.
S>>Строки, массивы могут создаваться на стороне клиента и передаваться в объект. Да и объекты могут создаваться в разных DLL.
S>>Еще раз все объекты должны поддерживать подсчет ссылок.
EP>Создание и удаление объекта происходит на одной стороне. Создание в CreateInstance, удаление грубо говоря в Release. Оба метода предоставляются одним и тем же лицом, и работают с одним и тем же менеджером памяти — с тем который определит автор этих методов (например автор соответствующей DLL).
Тогда в объекте должна быть ссылка на свой менеджер памяти и удаление через него. Это же по сути виртуальный деструктор
EP>На стороне клиента объект нигде в явном виде не создаётся и не удаляется, грубо говоря нет никаких new и delete.
На стороне клиента есть строки ,SafeArray. Кроме того в Net есть GAC где при создании объекта будет использоваться одна DLL. Если объекты создаются из разных DLL пусть это даже будут копии, то это уже будут разные типы. И при передаче параметра будет вызвано исключение.
Кроме того в двух DLL могут быть разные версии класса, что приводит к повреждению памяти.
И при передаче данных из разных DLL это еще и разные враперы.
S>>>>Все классы поддерживают подсчет ссылок?
EP>>>Это всё прекрасно реализуется неинтрузивно.
EP>>>Нет подсчёта ссылок:
EP>>>
EP>>>
S>>Ну вот у тебя есть две структуры. Кто и когда будет удалять объекты находящихся в полях структуры.
EP>Они удалятся автоматически вместе с аггрегирующей их структурой.
Автоматически когда? И почему они должны удаляться если на них есть ссылка на клиенте (во врапере)? Все объекты должны поддерживать подсчет ссылок
S>>По сути тебе нужно, что бы все классы поддерживали подсчет ссылок.
EP>Зачем все?
Плохо читаешь.
Есть объект у которого куча полей с объектами. На стороне клиента получили поле через 2 точки. Создался врапер.
Теперь все объекты полей кроме того на который есть ссылка клиента могут удалиться.
Получается, что все должны поддерживать счетчик, такие ссылки хранить отдельно например в Хэш таблице и перед удалением смотреть если они во враперах.
Но ведь это не так.
Просто вся прелесть Net в том, что все выполняется в единой среде? c информацией о типе и контроле типа, которая разруливает кучу взаимосвязей.
EP>Здравствуйте, Serginio1, Вы писали:
EP>>>Это исходный класс что-ли предварительное описание?
S>>Ну вообще то да. Или у вас все с открытыми кодами?
EP>Для этого достаточно заголовков (.h/.hpp). Или ты опять предлагаешь враппить произвольные бинарники?
S>>Swig делает в итоге делает предварительное описание.
EP>Он генерирует необходимый клей.
Не клей, а прокси класс.
S>>>>>>Как ваш описатель врапера разберется с зоопарком менеджеров памяти?
EP>>>>>Каким зоопарком? Ты о чём?
S>>>> То есть у вас как в Delphi один менеждер памяти?
EP>>>Не один, и здесь в этом нет проблемы. COM объекты создаются и удаляются на одной стороне.
S>> Это когда это такое было?
EP>Всегда.
S>>Вся прелесть COM в том, что используется единый менеджер памяти.
S>>Строки, массивы могут создаваться на стороне клиента и передаваться в объект. Да и объекты могут создаваться в разных DLL.
S>>Еще раз все объекты должны поддерживать подсчет ссылок.
EP>Создание и удаление объекта происходит на одной стороне. Создание в CreateInstance, удаление грубо говоря в Release. Оба метода предоставляются одним и тем же лицом, и работают с одним и тем же менеджером памяти — с тем который определит автор этих методов (например автор соответствующей DLL).
Тогда в объекте должна быть ссылка на свой менеджер памяти и удаление через него. Это же по сути виртуальный деструктор
EP>На стороне клиента объект нигде в явном виде не создаётся и не удаляется, грубо говоря нет никаких new и delete.
На стороне клиента есть строки ,SafeArray. Кроме того в Net есть GAC где при создании объекта будет использоваться одна DLL. Если объекты создаются из разных DLL пусть это даже будут копии, то это уже будут разные типы. И при передаче параметра будет вызвано исключение.
Кроме того в двух DLL могут быть разные версии класса, что приводит к повреждению памяти.
И при передаче данных из разных 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>>По сути тебе нужно, что бы все классы поддерживали подсчет ссылок.
EP>Зачем все?
Плохо читаешь.
Есть объект у которого куча полей с объектами. На стороне клиента получили поле через 2 точки. Создался врапер.
Теперь все объекты полей кроме того на который есть ссылка клиента могут удалиться.
Получается, что все должны поддерживать счетчик, такие ссылки хранить отдельно например в Хэш таблице и перед удалением смотреть если они во враперах.
Но ведь это не так.
Просто вся прелесть Net в том, что все выполняется в единой среде? c информацией о типе и контроле типа, которая разруливает кучу взаимосвязей.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
EP>>>Это исходный класс что-ли предварительное описание?
S>>Ну вообще то да. Или у вас все с открытыми кодами?
EP>Для этого достаточно заголовков (.h/.hpp). Или ты опять предлагаешь враппить произвольные бинарники?
S>>Swig делает в итоге делает предварительное описание.
EP>Он генерирует необходимый клей.
Не клей, а прокси класс.
S>>>>>>Как ваш описатель врапера разберется с зоопарком менеджеров памяти?
EP>>>>>Каким зоопарком? Ты о чём?
S>>>> То есть у вас как в Delphi один менеждер памяти?
EP>>>Не один, и здесь в этом нет проблемы. COM объекты создаются и удаляются на одной стороне.
S>> Это когда это такое было?
EP>Всегда.
S>>Вся прелесть COM в том, что используется единый менеджер памяти.
S>>Строки, массивы могут создаваться на стороне клиента и передаваться в объект. Да и объекты могут создаваться в разных DLL.
S>>Еще раз все объекты должны поддерживать подсчет ссылок.
EP>Создание и удаление объекта происходит на одной стороне. Создание в CreateInstance, удаление грубо говоря в Release. Оба метода предоставляются одним и тем же лицом, и работают с одним и тем же менеджером памяти — с тем который определит автор этих методов (например автор соответствующей DLL).
Тогда в объекте должна быть ссылка на свой менеджер памяти и удаление через него. Это же по сути виртуальный деструктор
EP>На стороне клиента объект нигде в явном виде не создаётся и не удаляется, грубо говоря нет никаких new и delete.
На стороне клиента есть строки ,SafeArray. Кроме того в Net есть GAC где при создании объекта будет использоваться одна DLL. Если объекты создаются из разных DLL пусть это даже будут копии, то это уже будут разные типы. И при передаче параметра будет вызвано исключение.
Кроме того в двух DLL могут быть разные версии класса, что приводит к повреждению памяти.
И при передаче данных из разных DLL это еще и разные враперы.
S>>>>Все классы поддерживают подсчет ссылок?
EP>>>Это всё прекрасно реализуется неинтрузивно.
EP>>>Нет подсчёта ссылок:
EP>>>
EP>>>
S>>Ну вот у тебя есть две структуры. Кто и когда будет удалять объекты находящихся в полях структуры.
EP>Они удалятся автоматически вместе с аггрегирующей их структурой.
Автоматически когда? И почему они должны удаляться если на них есть ссылка на клиенте (во врапере)? Все объекты должны поддерживать подсчет ссылок
S>>По сути тебе нужно, что бы все классы поддерживали подсчет ссылок.
EP>Зачем все?
Плохо читаешь.
Есть объект у которого куча полей с объектами. На стороне клиента получили поле через 2 точки. Создался врапер.
Теперь все объекты полей кроме того на который есть ссылка клиента могут удалиться.
Получается, что все должны поддерживать счетчик, такие ссылки хранить отдельно например в Хэш таблице и перед удалением смотреть если они во враперах.
Но ведь это не так. Не все классы поддерживают подсчет ссылок.
Просто вся прелесть Net в том, что все выполняется в единой среде c информацией о типе и контроле типа, которая разруливает кучу взаимосвязей.
Ну и конечно твой нелюбимый GC
EP>Здравствуйте, Serginio1, Вы писали:
EP>>>Это исходный класс что-ли предварительное описание?
S>>Ну вообще то да. Или у вас все с открытыми кодами?
EP>Для этого достаточно заголовков (.h/.hpp). Или ты опять предлагаешь враппить произвольные бинарники?
S>>Swig делает в итоге делает предварительное описание.
EP>Он генерирует необходимый клей.
Не клей, а прокси класс.
S>>>>>>Как ваш описатель врапера разберется с зоопарком менеджеров памяти?
EP>>>>>Каким зоопарком? Ты о чём?
S>>>> То есть у вас как в Delphi один менеждер памяти?
EP>>>Не один, и здесь в этом нет проблемы. COM объекты создаются и удаляются на одной стороне.
S>> Это когда это такое было?
EP>Всегда.
S>>Вся прелесть COM в том, что используется единый менеджер памяти.
S>>Строки, массивы могут создаваться на стороне клиента и передаваться в объект. Да и объекты могут создаваться в разных DLL.
S>>Еще раз все объекты должны поддерживать подсчет ссылок.
EP>Создание и удаление объекта происходит на одной стороне. Создание в CreateInstance, удаление грубо говоря в Release. Оба метода предоставляются одним и тем же лицом, и работают с одним и тем же менеджером памяти — с тем который определит автор этих методов (например автор соответствующей DLL).
Тогда в объекте должна быть ссылка на свой менеджер памяти и удаление через него. Это же по сути виртуальный деструктор
EP>На стороне клиента объект нигде в явном виде не создаётся и не удаляется, грубо говоря нет никаких new и delete.
На стороне клиента есть строки ,SafeArray. Кроме того в Net есть GAC где при создании объекта будет использоваться одна DLL. Если объекты создаются из разных DLL пусть это даже будут копии, то это уже будут разные типы. И при передаче параметра будет вызвано исключение.
Кроме того в двух DLL могут быть разные версии класса, что приводит к повреждению памяти.
И при передаче данных из разных 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>>По сути тебе нужно, что бы все классы поддерживали подсчет ссылок.
EP>Зачем все?
Плохо читаешь.
Есть объект у которого куча полей с объектами. На стороне клиента получили поле через 2 точки. Создался врапер.
Теперь все объекты полей кроме того на который есть ссылка клиента могут удалиться.
Получается, что все должны поддерживать счетчик, такие ссылки хранить отдельно например в Хэш таблице и перед удалением смотреть если они во враперах.
Но ведь это не так. Не все классы поддерживают подсчет ссылок.
Просто вся прелесть Net в том, что все выполняется в единой среде c информацией о типе и контроле типа, которая разруливает кучу взаимосвязей.
Ну и конечно твой нелюбимый GC