Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
EP>>>>>>>Причём тут "во время исполнения"? Ты свой класс, для которого нужен IDispatch, меняешь в runtime? Ты этого не говорил в условии S>>>>>> Я беру любую нетовскую сборку и использую её. EP>>>>>От native варианта ты что хочешь? Взять любую DLL и сделать к ней wrapper? S>>>> Мой врапер работает с любой DLL без предварительного описания. В рефлекшине все есть. EP>>>Нет, не с любой S>>Докажи.
EP>Возьми любую native dll
Я говорил про любую нетовскую. Кстати может и не все нетовские если он обфусцирован. Правда ни разу с ними не работал S>>>>>>Есть свои сборки. То есть любую без предварительного описания. EP>>>>>Ещё раз, SWIG не требует предварительного описания. S>>>> А что делает SWIG? Ты должен получить врапер причем статически. Или он компилирует на лету по исходникам? EP>>>Он делает весь glue code по исходникам. S>> Ну вот, а говоришь, что не требует предварительного описания.
EP>Это исходный класс что-ли предварительное описание?
Ну вообще то да. Или у вас все с открытыми кодами? Swig делает в итоге делает предварительное описание.
S>>>>>>В Net value тип боксится EP>>>>>В C++ объект любого типа можно создать где угодно (не считая несколько экстремальных случаев к теме не относящихся) — в любой кучке байт достаточного размера S>>>>Кстати в примерах только value типы. Нет там примеров с объектами, типами итд. S>>>>Как ваш описатель врапера разберется с зоопарком менеджеров памяти? EP>>>Каким зоопарком? Ты о чём? S>> То есть у вас как в Delphi один менеждер памяти?
EP>Не один, и здесь в этом нет проблемы. COM объекты создаются и удаляются на одной стороне.
Это когда это такое было? Вся прелесть COM в том, что используется единый менеджер памяти.
Строки, массивы могут создаваться на стороне клиента и передаваться в объект. Да и объекты могут создаваться в разных DLL.
Еще раз все объекты должны поддерживать подсчет ссылок.
S>>Все классы поддерживают подсчет ссылок?
EP>Это всё прекрасно реализуется неинтрузивно. EP>Нет подсчёта ссылок: EP>
EP>struct Widget
EP>{
EP> Data x;
EP>};
EP>
Легким движением руки подсчёт ссылок появляется: EP>
EP>shared_ptr<Widget> ref_counted_widget;
EP>
Ну вот у тебя есть две структуры. Кто и когда будет удалять объекты находящихся в полях структуры.
По сути тебе нужно, что бы все классы поддерживали подсче ссылок.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>И то что "извращения java" никуда не делись. Он всего лишь рассказал про один аспект задачи, который никак не отменяет другие. dot>>На плюсах были бы те же извращения. EP>Это демагогия чистой воды, непонятно на кого рассчитанная EP>В ролике действительно есть описание тех аспектов которые были бы на C++, их даже извращением трудно назвать — банальное affinity. EP>Помимо этого есть извращения с GC-free, off-heap — их выступающий упомянул только вскользь, мол да — надо как-то решать. Вот этих извращений на C++ бы не было
Решается, конечно. Но каких либо особенных сложностей нет. Там где gc-free — в плюсах будут alloc-free или хитровывернутые аллокаторы. Там где offheap или нарезание на массивы — будут structure-of-arrays.
dot>>>>А в плюсах выбора нет. EP>>>GC для C++ существуют (и их применяют) как минимум с начала девяностых годов / конца восьмидесятых. В стандарте C++11 появилось специальное API для GC. EP>>>Причём реализации возможны как библиотечные, так и runtime. dot>>Ой, да не прикалывайся. EP>Не прикалываюсь
И как оказалось по факту есть только boehm
EP>Например Boehm GC есть очень давно, и используется в реальных проектах
Он используется в особенного типа проектов — gcj, mono, lisp и т.п. Прикладной код, а уж тем более LL — что-то очень сомневаюсь.
dot>>>>К тому, что java уже давно побороли... Большинство выкрутасов это не "извращения java", а именно LL, EP>>>Из этого видео никак не следует что "большинство выкрутасов это не извращения java". dot>>Это те проблемы, которые сейчас решают в LMAX, хотя всё ещё пишут всё на "извратной java". EP>От того что он сорок минут рассказывал про affinity, проблемы с извращениями на Java никуда не делись, он их даже явно упомянул.
Да сколько раз повторять. Нет проблем никаких.
dot>>>>может быть синтаксис не очень, и код непривычен, но помехой не является. EP>>>И уровень кода ниже чем C, и больше его во много раз. dot>>Не знаю что тут значит "уровень кода", но это не важно. EP>На C есть структуры — это выше уровнем чем ручное нарезание буферов.
И что они дают? Без них всё работает замечательно, зачем лишняя сущность?
dot>>Все преимущества java никуда не деваются. EP>Конечно теряются — например появляются те самые расстрелы памяти
Во-первых, такие извращения делаются только в очень небольшом участке кода, дай боже 1% от всей системы, во-вторых, эти расстрелы мало на что могут повлиять, очень ограниченный кусок кода. В-третьих, этот кусок кода довольно примитивный, при желании можно даже формально доказать отсутствие расстрелов. В-четвёртых, этот кусок кода (раз уж его так заоптимизировать пришлось) очень горячий, соответственно практически все баги выцепляются ещё юнит-тестами. В-пятых, обычно это красиво оборачивается, например, в Disruptor, за много лет отлаженная библиотека.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Serginio1, Вы писали:
EP>>Это исходный класс что-ли предварительное описание? S>Ну вообще то да. Или у вас все с открытыми кодами?
Для этого достаточно заголовков (.h/.hpp). Или ты опять предлагаешь враппить произвольные бинарники?
S>Swig делает в итоге делает предварительное описание.
Он генерирует необходимый клей.
S>>>>>Как ваш описатель врапера разберется с зоопарком менеджеров памяти? EP>>>>Каким зоопарком? Ты о чём? S>>> То есть у вас как в Delphi один менеждер памяти? EP>>Не один, и здесь в этом нет проблемы. COM объекты создаются и удаляются на одной стороне. S> Это когда это такое было?
Всегда.
S>Вся прелесть COM в том, что используется единый менеджер памяти. S>Строки, массивы могут создаваться на стороне клиента и передаваться в объект. Да и объекты могут создаваться в разных DLL. S>Еще раз все объекты должны поддерживать подсчет ссылок.
Создание и удаление объекта происходит на одной стороне. Создание в CreateInstance, удаление грубо говоря в Release. Оба метода предоставляются одним и тем же лицом, и работают с одним и тем же менеджером памяти — с тем который определит автор этих методов (например автор соответствующей DLL).
На стороне клиента объект нигде в явном виде не создаётся и не удаляется, грубо говоря нет никаких new и delete.
S>>>Все классы поддерживают подсчет ссылок? EP>>Это всё прекрасно реализуется неинтрузивно. EP>>Нет подсчёта ссылок: EP>>
EP>>struct Widget
EP>>{
EP>> Data x;
EP>>};
EP>>
Легким движением руки подсчёт ссылок появляется: EP>>
EP>>shared_ptr<Widget> ref_counted_widget;
EP>>
S>Ну вот у тебя есть две структуры. Кто и когда будет удалять объекты находящихся в полях структуры.
Они удалятся автоматически вместе с аггрегирующей их структурой.
S>По сути тебе нужно, что бы все классы поддерживали подсче ссылок.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
EP>>>Это исходный класс что-ли предварительное описание? S>>Ну вообще то да. Или у вас все с открытыми кодами?
EP>Для этого достаточно заголовков (.h/.hpp). Или ты опять предлагаешь враппить произвольные бинарники?
Я не предлагаю. Я это делаю для нетовских DLL 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
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, ·, Вы писали:
EP>>>>И то что "извращения java" никуда не делись. Он всего лишь рассказал про один аспект задачи, который никак не отменяет другие. dot>>>На плюсах были бы те же извращения. EP>>Это демагогия чистой воды, непонятно на кого рассчитанная EP>>В ролике действительно есть описание тех аспектов которые были бы на C++, их даже извращением трудно назвать — банальное affinity. EP>>Помимо этого есть извращения с GC-free, off-heap — их выступающий упомянул только вскользь, мол да — надо как-то решать. Вот этих извращений на C++ бы не было dot>Решается, конечно.
Да, всё решаемо.
dot>Но каких либо особенных сложностей нет.
Привыкли есть кактус
dot>Там где gc-free — в плюсах будут alloc-free или хитровывернутые аллокаторы.
Не факт что вообще будет отступление от дефолта. Так как в C++ аллокаций на порядки меньше. vector<tuple<tuple<tuple<tuple<tuple<tuple<int>>>>>>>(1u << 30) выделяется за одну аллокацию.
Да и специальный аллокатор по сути на удобство не влияет — поменял шаблонный аргумент и готово. Уж точно ни в какое сравнение с GC-Free.
dot>Там где offheap или нарезание на массивы — будут structure-of-arrays.
Сам же понимаешь что это передёргивание.
Там где на Java будут нарезать массивы на структуры, по сути инстанциировать вручную все алгоритмы и контейнеры с этими структурами — на C++ будут обычные дефолтные структуры.
Там где на Java будет нарезать на structure-of-arrays с теми же неудобствами — на C++ будет автоматическая библиотечная метапрограммная трансформация, которая выдаст такой же интерфейс как и прежде.
Причём SoA требуются на порядки реже чем обычные структуры.
dot>>>>>А в плюсах выбора нет. EP>>>>GC для C++ существуют (и их применяют) как минимум с начала девяностых годов / конца восьмидесятых. В стандарте C++11 появилось специальное API для GC. EP>>>>Причём реализации возможны как библиотечные, так и runtime. dot>>>Ой, да не прикалывайся. EP>>Не прикалываюсь dot>И как оказалось по факту есть только boehm
Есть в Mozilla, я тебе это уже неоднократно говорил. А вообще да — спроса на них практически нет
EP>>Например Boehm GC есть очень давно, и используется в реальных проектах dot>Он используется в особенного типа проектов — gcj, mono, lisp и т.п. Прикладной код, а уж тем более LL — что-то очень сомневаюсь.
Например Inkscape — вполне прикладной код http://wiki.inkscape.org/wiki/index.php/Tracking_Dependencies#Boehm-GC
dot>>>>>К тому, что java уже давно побороли... Большинство выкрутасов это не "извращения java", а именно LL, EP>>>>Из этого видео никак не следует что "большинство выкрутасов это не извращения java". dot>>>Это те проблемы, которые сейчас решают в LMAX, хотя всё ещё пишут всё на "извратной java". EP>>От того что он сорок минут рассказывал про affinity, проблемы с извращениями на Java никуда не делись, он их даже явно упомянул. dot>Да сколько раз повторять. Нет проблем никаких.
То есть ты извращения с off-heap за проблемы не считаешь? Ну ок
dot>>>>>может быть синтаксис не очень, и код непривычен, но помехой не является. EP>>>>И уровень кода ниже чем C, и больше его во много раз. dot>>>Не знаю что тут значит "уровень кода", но это не важно. EP>>На C есть структуры — это выше уровнем чем ручное нарезание буферов. dot>И что они дают?
Например абстракцию над пачкой байт лежащих в массиве.
dot>Без них всё работает замечательно, зачем лишняя сущность?
Несерьёзно, это уже blub-аргументация.
dot>во-вторых, эти расстрелы мало на что могут повлиять, очень ограниченный кусок кода.
Действительно, подумаешь код не работает.
Для C++ кстати есть готовые инструменты типа valgrind, которые гоняются параллельно тестам. А вот чем ловить расстрел буфера в off-heap?
dot>В-третьих, этот кусок кода довольно примитивный, при желании можно даже формально доказать отсутствие расстрелов.
.
dot>В-четвёртых, этот кусок кода (раз уж его так заоптимизировать пришлось) очень горячий, соответственно практически все баги выцепляются ещё юнит-тестами.
Конечно найдутся, сначала куча времени угробится на работу которую компиляторы умеют не одно десятилетие, потом куча времени угробится на отладку. Здорово.
dot>В-пятых, обычно это красиво оборачивается, например, в Disruptor, за много лет отлаженная библиотека.
Здравствуйте, 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>>>>
S>>>Ну вот у тебя есть две структуры. Кто и когда будет удалять объекты находящихся в полях структуры. EP>>Они удалятся автоматически вместе с аггрегирующей их структурой. S> Автоматически когда?
После того как отработает тело деструктора аггрегирующей их структуры.
S>И почему они должны удаляться если на них есть ссылка на клиенте (во врапере)?
А как он к ним получил доступ?
S>Все объекты должны поддерживать подсчет ссылок
Нет, не все.
S>>>По сути тебе нужно, что бы все классы поддерживали подсчет ссылок. EP>>Зачем все? S> Плохо читаешь.
Что конкретно я плохо читаю? То что ты там задним числом наредактировал?
S>Есть объект у которого куча полей с объектами. На стороне клиента получили поле через 2 точки.
Каким образом?
S>Создался врапер.
Когда? Где? Кем? И каким образом?
S>Ну и конечно твой нелюбимый GC
Почему нелюбимый? Без проблем использую языки с GC, о чём тебе лично уже пару раз сказал. Я даже как-то делал копирующий GC for fun.
Да и причём тут GC?
. S>>>>Вся прелесть COM в том, что используется единый менеджер памяти. S>>>>Строки, массивы могут создаваться на стороне клиента и передаваться в объект. Да и объекты могут создаваться в разных DLL. S>>>>Еще раз все объекты должны поддерживать подсчет ссылок. EP>>>Создание и удаление объекта происходит на одной стороне. Создание в CreateInstance, удаление грубо говоря в Release. Оба метода предоставляются одним и тем же лицом, и работают с одним и тем же менеджером памяти — с тем который определит автор этих методов (например автор соответствующей DLL). S>> Тогда в объекте должна быть ссылка на свой менеджер памяти и удаление через него.
EP>Она есть. В простейшем виде такая ссылка зашита в самом коде методов CreateInstance и Release. EP>А нужные методы вызываются правильным выбором vtable ptr, который находится по указателю с которым работает пользователь.
S>>Это же по сути виртуальный деструктор
EP>В обязанности деструктора не входит очистка памяти. Его например можно вызывать без очистки памяти. EP>Release грубо говоря это виртуальный метод который внутри делает что-то типа if(--counter == 0) delete this;, а уже delete вызывает деструктор (который даже может быть не виртуальным) и очищает память.
Тогда C++ это тормоза. А ты говоришь о скорости. S>>Если объекты создаются из разных DLL пусть это даже будут копии, то это уже будут разные типы. И при передаче параметра будет вызвано исключение.
EP>Какого параметра?
У класса есть методы, у метода есть параметры, в том числе и out S>>Кроме того в двух DLL могут быть разные версии класса, что приводит к повреждению памяти.
EP>Из-за чего? EP>Объекты могут быть разных версий, иметь разные менеджеры памяти, и при этом прекрасно сочетаться друг с другом
А обращаться к несуществующим полям, или массивам меньшей длины? S>> И при передаче данных из разных DLL это еще и разные враперы.
EP>И что?
А то, что разные версии Swig и соответственно разные поля S>>>>>>Все классы поддерживают подсчет ссылок? S>>>>Ну вот у тебя есть две структуры. Кто и когда будет удалять объекты находящихся в полях структуры. EP>>>Они удалятся автоматически вместе с аггрегирующей их структурой. S>> Автоматически когда?
EP>После того как отработает тело деструктора аггрегирующей их структуры.
S>>И почему они должны удаляться если на них есть ссылка на клиенте (во врапере)?
EP>А как он к ним получил доступ?
А как ты получаешь доступ к полям, свойствам объекта.
S>>Все объекты должны поддерживать подсчет ссылок
EP>Нет, не все.
S>>>>По сути тебе нужно, что бы все классы поддерживали подсчет ссылок. EP>>>Зачем все? S>> Плохо читаешь.
EP>Что конкретно я плохо читаю? То что ты там задним числом наредактировал?
Я тебе уже кучу времени долблю про деревья, и то что у клиента должен быть доступ к любому публичному (в Net можно к любому) полю, свойству
S>>Есть объект у которого куча полей с объектами. На стороне клиента получили поле через 2 точки.
EP>Каким образом?
А как ты достаешь Объект.Поле1.Тратаьа S>>Создался врапер.
EP>Когда? Где? Кем? И каким образом?
Не знаю, что там твой SWIG нагородил S>>Ну и конечно твой нелюбимый GC
EP>Почему нелюбимый? Без проблем использую языки с GC, о чём тебе лично уже пару раз сказал. Я даже как-то делал копирующий GC for fun. EP>Да и причём тут GC?
А то, что не нужен подсчет ссылок в объекте. GC сам ведет подсчет.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
EP>>>Это исходный класс что-ли предварительное описание? S>>Ну вообще то да. Или у вас все с открытыми кодами?
EP>Для этого достаточно заголовков (.h/.hpp). Или ты опять предлагаешь враппить произвольные бинарники?
Кстати Сборка Net это не только DLL. Это том числе и Exe.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
EP>>>>>Это исходный класс что-ли предварительное описание? S>>>>Ну вообще то да. Или у вас все с открытыми кодами? EP>>>Для этого достаточно заголовков (.h/.hpp). Или ты опять предлагаешь враппить произвольные бинарники? S>>Я не предлагаю. Я это делаю для нетовских DLL S>>>>Swig делает в итоге делает предварительное описание. EP>>>Он генерирует необходимый клей. S>> Не клей, а прокси класс.
EP>Клей. EP>
EP>http://www.swig.org/
EP>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.
А ты вообще представляешь какой результирующий врапер должен получиться если делать ко всем DLL.
При этом реально то нужно совсем немного. Но это заранее неизвестно. А теперь сравни размер моей функции и предполагаемый врапер по всем возможным DLL.
А ведь для Net с точки зрения классов нет большой разницы между DLL и EXE.
Кстати а чем С++ хуже питона, раз питон используется с С++?
C# точно ничем не хуже.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
EP>>>>Он генерирует необходимый клей. S>>> Не клей, а прокси класс. EP>>Клей. EP>>
EP>>http://www.swig.org/
EP>>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> А ты вообще представляешь какой результирующий врапер должен получиться если делать ко всем DLL.
Зачем ко всем? К каким всем?
S>При этом реально то нужно совсем немного. Но это заранее неизвестно. А теперь сравни размер моей функции и предполагаемый врапер по всем возможным DLL.
По каким всем возможным? Речь изначально шла про какой-то один тип.
Если же тебе нужно что-то типа REPL (для чего?), то тогда уже надо смотреть в сторону интерпретатора C++ — Cling.
S>А ведь для Net с точки зрения классов нет большой разницы между DLL и EXE.
К чему это вообще?
S> Кстати а чем С++ хуже питона, раз питон используется с С++?
Ты о чём вообще?
S> Кстати а чем С++ хуже питона, раз питон используется с С++? S>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> Кстати единственный вариант , это когда есть подсчет ссылок. Я так понимаю, что у вас там куча вариантов даже по этой теме
S> Возьмем пример. Например у тебя есть структура с кучей полей объектов этакое дерево с циклическими ссылками
S>И тебе эту структуру нужно передать на сторону клиента. Врапер структуру обернул. Но у структуры то нет подсчета ссылок?
Подсчёт ссылок есть у враппера — он предоставляет AddRef/Release, которые должен дёргать клиент в соответствии с протоколом COM.
Если например запрашивается свойство не примитивного типа — возвращается новый враппер, при этом если у этого свойства в оригинале нет своего подсчёта ссылок, то будет использоваться счётчик агрегирующего объекта.
S>>>Ну и конечно твой нелюбимый GC EP>>Почему нелюбимый? Без проблем использую языки с GC, о чём тебе лично уже пару раз сказал. Я даже как-то делал копирующий GC for fun. EP>>Да и причём тут GC? S> А то, что не нужен подсчет ссылок в объекте. GC сам ведет подсчет.
Счётчик должен быть внутри компонента, это базовый интерфейс — IUnknown. То что конкретные клиенты могут вызывать AddRef/Release на основе разных подходов — дело десятое, и не снимает необходимости в вызове этих AddRef/Release
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
EP>>>>>Он генерирует необходимый клей. S>>>> Не клей, а прокси класс. EP>>>Клей. EP>>>
EP>>>http://www.swig.org/
EP>>>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>> А ты вообще представляешь какой результирующий врапер должен получиться если делать ко всем DLL.
EP>Зачем ко всем? К каким всем?
Ко всем возможным. Я заранее не знаю какие сборки буду использовать. Этим будет заниматься программист 1С. S>>При этом реально то нужно совсем немного. Но это заранее неизвестно. А теперь сравни размер моей функции и предполагаемый врапер по всем возможным DLL.
EP>По каким всем возможным? Речь изначально шла про какой-то один тип. EP>Если же тебе нужно что-то типа REPL (для чего?), то тогда уже надо смотреть в сторону интерпретатора C++ — Cling.
Это ты о чем то думал. Я говорил о любом классе.
S>>А ведь для Net с точки зрения классов нет большой разницы между DLL и EXE.
EP>К чему это вообще?
К тому, что как ты будешь создавать классы из бинарника EXE где нет импорта функций, заголовков S>> Кстати а чем С++ хуже питона, раз питон используется с С++?
EP>Ты о чём вообще?
S>> Кстати а чем С++ хуже питона, раз питон используется с С++? S>>C# точно ничем не хуже.
EP>^^^^ Прочти то что сам написал, и попробуй расшифруй что это значит.
Вы используете питон для написания приложений. В этой ветке не раз подымался. Кроме того ты пример врапера именно для питона.
и солнце б утром не вставало, когда бы не было меня
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 нет.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
_>>Аааа, так оно ещё и через COM это делается... ) Тогда уж точно никакой разницы с другими языками нет, причём уже прямо сейчас. Т.е. банально реализуем соответствующий COM интерфейс и без проблем используем его в 1C. Не знаю правда зачем, но делается это тривиально. ))) S> Тебе нужно делать обертку Idispatch над объектом, типом. В Net это делается через Reflection к любому типу, объекту S>Раз это элементарно забацайка. В той статье класс оборачивает любой объект, тип. Поддержка энумераторов. S>Давай прямо сейчас.
Ну вообще то создание COM объектов в виде обёртки над существующими классами — это не самый лучший путь. По нормальному реализацию COM вставляют прямо в эти классы (мы же обычно заранее знаем, хотим ли мы поддерживать вызов нас через COM или нет). Соответственно реализация делается тривиально: http://doc.qt.io/qt-5/activeqt-activeqt-simple-example.html или например вот http://doc.qt.io/qt-5/activeqt-activeqt-comapp-example.html для полноценного приложения (exe) с документами и т.п., управляемого через COM.
Но если всё же есть большое желание создание COM обёртку над уже реализованными классами, то это естественно тоже не проблема: http://doc.qt.io/qt-5/activeqt-activeqt-wrapper-example.html.
S> Это еще раз подтверждение того, что ты невнимательно читаешь ссылки
Здравствуйте, Evgeny.Panasyuk, Вы писали: S>>>>Если объекты создаются из разных DLL пусть это даже будут копии, то это уже будут разные типы. И при передаче параметра будет вызвано исключение. EP>>>Какого параметра? S>> У класса есть методы, у метода есть параметры, в том числе и out
EP>Если у параметра тип который даёт единый ABI интерфейс для разных версий — то никаких проблем не будет.
S>>>>Кроме того в двух DLL могут быть разные версии класса, что приводит к повреждению памяти. EP>>>Из-за чего? EP>>>Объекты могут быть разных версий, иметь разные менеджеры памяти, и при этом прекрасно сочетаться друг с другом S>> А обращаться к несуществующим полям, или массивам меньшей длины?
EP>Проблемы будут есть вызывать методы одного класса на объекте другого. Если методы виртуальные и интерфейсы не поменялись, или вообще динамические а-ля Invoke — то проблемы не будет. EP>Если же у тебя в голове какой-то use-case, в котором метод одного класса вызывается на объекте другого класса — то так и опиши его, я мысли читать не умею.
Если если. А на самом деле могут меняться как поля, так и сигнатуры методов и VMT.
Кстати в Net поместил в GAC и все будут использовать одну версию. Либо могу передать объект врапера, где будут через рефлексию вызываться его методы и свойства.
Здравствуйте, Serginio1, Вы писали:
S>>> Кстати а чем С++ хуже питона, раз питон используется с С++? S>>>C# точно ничем не хуже.
C# менее гибкий для обобщённого кода. Например
Python:
def add(x, y):
return x + y
def sub(x, y):
return x - y
def apply(f, *args):
return f(*args)
print(apply(apply, apply, apply, add, 1, 2))
print(apply(apply, apply, sub, 11, 2))
C++:
auto add = [](auto x, auto y)
{
return x + y;
};
auto sub = [](auto x, auto y)
{
return x - y;
};
auto apply = [](auto f, auto... args)
{
return f(args...);
};
print(apply(apply, apply, apply, add, 1, 2));
print(apply(apply, apply, sub, 11, 2));
C#?
Да и по большей части ориентирован на одну платформу (afaik Mono постоянно в роли догоняющего), в то время как Python использую на Windows/Linux/OS X.
EP>>^^^^ Прочти то что сам написал, и попробуй расшифруй что это значит. S> Вы используете питон для написания приложений. В этой ветке не раз подымался.
Python использую в нескольких контекстах:
1. Автоматизация сборки и тестов, в дополнение к CMake.
2. Некоторый софт для инженеров, в основном склеивающий другие проекты.
В обоих случаях с этим же кодом работают люди знающие в основном только Python, для них программирование не является основным видом деятельности. То есть здесь это по большей части внешнее требование.
3. Всякие скрипты для личных нужд, работа с файлами, построение графиков, символьные вычисления и т.п.
Здесь бы подошёл и C++ (тем более C++14), но есть пара останавливающих факторов:
а) нет под рукой моментальных замен каким-то функциям/etc, точнее они даже есть — но нужно потратить время чтобы собрать это всё воедино, и сделать несколько обёрток чтобы было script-like.
б) нужно сделать workflow ближе к скриптам — настроить быструю компиляцию с запуском и/или интерпретацию через Cling.
И то и другое достижимо, но требует затрат времени, в то время как Python уже под рукой.
Были ещё какие-то use-case'ы, но сходу не вспомню.
S>Кроме того ты пример врапера именно для питона.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>Аааа, так оно ещё и через COM это делается... ) Тогда уж точно никакой разницы с другими языками нет, причём уже прямо сейчас. Т.е. банально реализуем соответствующий COM интерфейс и без проблем используем его в 1C. Не знаю правда зачем, но делается это тривиально. ))) S>> Тебе нужно делать обертку Idispatch над объектом, типом. В Net это делается через Reflection к любому типу, объекту S>>Раз это элементарно забацайка. В той статье класс оборачивает любой объект, тип. Поддержка энумераторов. S>>Давай прямо сейчас.
_>Ну вообще то создание COM объектов в виде обёртки над существующими классами — это не самый лучший путь. По нормальному реализацию COM вставляют прямо в эти классы (мы же обычно заранее знаем, хотим ли мы поддерживать вызов нас через COM или нет). Соответственно реализация делается тривиально: http://doc.qt.io/qt-5/activeqt-activeqt-simple-example.html или например вот http://doc.qt.io/qt-5/activeqt-activeqt-comapp-example.html для полноценного приложения (exe) с документами и т.п., управляемого через COM.
Еще раз моя обертка для любого нетовского класса, который 1С ник может использовать только зная имя класса если сборка загружена либо AssemblyQualifiedName
если сборка находится в GAC. _>Но если всё же есть большое желание создание COM обёртку над уже реализованными классами, то это естественно тоже не проблема: http://doc.qt.io/qt-5/activeqt-activeqt-wrapper-example.html.
S>> Это еще раз подтверждение того, что ты невнимательно читаешь ссылки
_>Эээ что? )
То, что привел пример универсальной обертки. Где не нужно делать каких либо действий, кроме подписки на события.
Это плюсы Net, где есть Reflection, заглушка к COM, GC. Чего нет в C++. А решать все через предварительное создание враперов не выход, так как я не знаю, чего захочет 1С ник (какие классы, сборки будет использовать), так как врапер универсальный и в real time. По сути это бесплатное расширение 1С. Но самый смех в том, что это мало кому нужно.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>>>>Если объекты создаются из разных DLL пусть это даже будут копии, то это уже будут разные типы. И при передаче параметра будет вызвано исключение. EP>>>>Какого параметра? S>>> У класса есть методы, у метода есть параметры, в том числе и out EP>>Если у параметра тип который даёт единый ABI интерфейс для разных версий — то никаких проблем не будет. S>Воо теперь нужно сравнивать не только тип, но и его эквивалентность
Я говорю не про сами типы, а про интерфейсы.
S>>>>>Кроме того в двух DLL могут быть разные версии класса, что приводит к повреждению памяти. EP>>>>Из-за чего? EP>>>>Объекты могут быть разных версий, иметь разные менеджеры памяти, и при этом прекрасно сочетаться друг с другом S>>> А обращаться к несуществующим полям, или массивам меньшей длины? EP>>Проблемы будут есть вызывать методы одного класса на объекте другого. Если методы виртуальные и интерфейсы не поменялись, или вообще динамические а-ля Invoke — то проблемы не будет. S> У тебя расположение полей может быть другое.
И что? К ним доступ напрямую не осуществляется, только через виртуальную таблицу.
EP>>Если же у тебя в голове какой-то use-case, в котором метод одного класса вызывается на объекте другого класса — то так и опиши его, я мысли читать не умею. S> А как ты понимаешь обращение к полям, вызов метода. Смещение полей, методов может меняться.
Ни смещение полей, ни методов, роли не играет пока мы к ним не обращаемся напрямую. Также не играет роли sizeof пока мы сами не создаём объекты.
S>Даже VMT и та может поменяться. Да и методы могут в реалии иметь другую сигнатуру.
Это уже изменение интерфейса.
EP>>Про деревья нашёл вот тут — то есть правка уже после того как я прочитал и начал отвечать. Ты если делаешь существенные правки — выноси их в отдельные сообщения S>Про валуе типы я подправил. А вот то, что полями могут быть экземпляры классов, как раз и говорит о деревьях. S>Так как полей объектов тоже могут быть поля объекты.
И что из этого?
EP>>Подсчёт ссылок есть у враппера — он предоставляет AddRef/Release, которые должен дёргать клиент в соответствии с протоколом COM. EP>>Если например запрашивается свойство не примитивного типа — возвращается новый враппер, при этом если у этого свойства в оригинале нет своего подсчёта ссылок, то будет использоваться счётчик агрегирующего объекта. S> Подсчет ссыло врапера не спасает, от того, что тебе нужно либо считать ссылки на объект, либо перед удалением искать ссылки во враперах
Подробнее.
S>>>>>Ну и конечно твой нелюбимый GC EP>>>>Почему нелюбимый? Без проблем использую языки с GC, о чём тебе лично уже пару раз сказал. Я даже как-то делал копирующий GC for fun. EP>>>>Да и причём тут GC? S>>> А то, что не нужен подсчет ссылок в объекте. GC сам ведет подсчет. EP>>Счётчик должен быть внутри компонента, это базовый интерфейс — IUnknown. То что конкретные клиенты могут вызывать AddRef/Release на основе разных подходов — дело десятое, и не снимает необходимости в вызове этих AddRef/Release S> То есть в С++ все классы реализуют IUnknown с автоматическим AddRef/Release? S>Такого даже в Delphi нет.
Ещё раз, они реализуются неинтрузивно, тем более когда речь идёт о враппере под IDispatch.
Здравствуйте, Serginio1, Вы писали:
S> Еще раз моя обертка для любого нетовского класса, который 1С ник может использовать только зная имя класса если сборка загружена либо AssemblyQualifiedName S>если сборка находится в GAC.
Ну так а для использования из 1C C++ кода, сделанного с поддержкой COM'a даже и никакие обёртки не нужны.
S>>> Это еще раз подтверждение того, что ты невнимательно читаешь ссылки _>>Эээ что? ) S> То, что привел пример универсальной обертки. Где не нужно делать каких либо действий, кроме подписки на события. S>Это плюсы Net, где есть Reflection, заглушка к COM, GC. Чего нет в C++. А решать все через предварительное создание враперов не выход, так как я не знаю, чего захочет 1С ник (какие классы, сборки будет использовать), так как врапер универсальный и в real time. По сути это бесплатное расширение 1С. Но самый смех в том, что это мало кому нужно.
Вообще то мы сравнивали сложность написания C# и C++ кода, который потом будут вызывать из 1C. Так вот в этом разницы не видно. Если же ты хочешь поговорить о возможности запуска из 1C некого чужого, скомпилированного в бинарник кода, то это уже совсем другой вопрос для другой дискуссии.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
S>>>> Кстати а чем С++ хуже питона, раз питон используется с С++? S>>>>C# точно ничем не хуже.
EP>C# менее гибкий для обобщённого кода. Например EP>Python: EP>
EP>def add(x, y):
EP> return x + y
EP>def sub(x, y):
EP> return x - y
EP>def apply(f, *args):
EP> return f(*args)
EP>print(apply(apply, apply, apply, add, 1, 2))
EP>print(apply(apply, apply, sub, 11, 2))
EP>
https://msdn.microsoft.com/ru-ru/library/39bb81c3.aspx
Ну и джененрики интефейсы EP>Да и по большей части ориентирован на одну платформу (afaik Mono постоянно в роли догоняющего), в то время как Python использую на Windows/Linux/OS X.
Сейчас будут развиваться параллельно так же. EP>>>^^^^ Прочти то что сам написал, и попробуй расшифруй что это значит. S>> Вы используете питон для написания приложений. В этой ветке не раз подымался.
EP>Python использую в нескольких контекстах:
EP>1. Автоматизация сборки и тестов, в дополнение к CMake. EP>2. Некоторый софт для инженеров, в основном склеивающий другие проекты.
EP>В обоих случаях с этим же кодом работают люди знающие в основном только Python, для них программирование не является основным видом деятельности. То есть здесь это по большей части внешнее требование.
EP>3. Всякие скрипты для личных нужд, работа с файлами, построение графиков, символьные вычисления и т.п.
То есть, что не удобно делать на С++. EP>Здесь бы подошёл и C++ (тем более C++14), но есть пара останавливающих факторов: EP>а) нет под рукой моментальных замен каким-то функциям/etc, точнее они даже есть — но нужно потратить время чтобы собрать это всё воедино, и сделать несколько обёрток чтобы было script-like. EP>б) нужно сделать workflow ближе к скриптам — настроить быструю компиляцию с запуском и/или интерпретацию через Cling. EP>И то и другое достижимо, но требует затрат времени, в то время как Python уже под рукой.
Вот а в C# практически все в одном. EP>Были ещё какие-то use-case'ы, но сходу не вспомню.
S>>Кроме того ты пример врапера именно для питона.
EP>Первое что под руку попалось.
и солнце б утром не вставало, когда бы не было меня