CXXI: Мост между мирами C# и C++

[@bobermaniac]

C++/CLI разве не решает эту проблему проще?

[@kekekeks]

Если написание glue-кода вручную и наличие в итоговой сборке native-кода, привязанного к архитектуре процессора и неработающего нигде кроме Windows, проще, то да.

[@bobermaniac]

В любом случае откомпилированная библиотека на C++ будет привязана к архитектуе процессора и в ней будет native код.

Я не предлагаю писать все на C++/CLI, но налаживать на нем мосты довольно удобно.

[@kekekeks]

Ну там вам надо делать мост, тут вам дают возможность без написания дополнительного кода получить доступ к классам C++. В любом случае сборки C++/CLI гвоздями приколочены к MSVCRT, так что для Mono (в рамках которого и пилят CXXI) они бесполезны.

[@bobermaniac]

Я несколько опасаюсь автоматических прокси-генераторов неуправляемого кода в управляемый — у них раньше была тенденция злоупотреблять IntPtr.

Возможно, если эти ребята побороли эту проблему, то штука на самом деле полезная.

[@szKarlen]

основной вопрос здесь не в написании байндингов, а в их автоматической генерации.
примерно такой же подход использует проект SharpDX.
API генерируется напрямую из заголовочных файлов DirectX SDK.

[@tangro]

Лично я настроен скептично. Ну то есть я верю, что они допишут это всё и оно даже будет работать. Мне не нравится идеология. Люди, которые осознанно решают использовать из C# кода классы C++ делают это по вполне понятным причинам: им не хватает производительности или управляемости или ручного управления памятью. Потому они садятся, и пишут руками на С++ все плохо реализуемые в С# вещи (включая взаимодействие С# и С++ кода). А тут этот значительный и серьёзный кусок за них сгенерит какая-то непонятная хрень. Ну и о каком контроле управляемости\производительности\памяти может идти речь?

[@kekekeks]

Люди, которые осознанно решают использовать из C# кода классы C++ делают это по вполне понятным причинам: им не хватает производительности или управляемости или ручного управления памятью.

Эм. Есть тонны готового, работающего и протестированного кода на C++. Зачем его переписывать на шарп? Возьмите то же Qt — переписать всё это на шарп да ещё и так, чтобы работало на всех поддерживаемых Qt платформах не представляется возможным. Таким образом CXXI — главным образом инструмент для создания биндингов к готовым библиотекам, а не смешанных приложений.

[@ganouver]

Идея занятная, но, честно говоря, я не очень понял восторгов насчет кроссплатформенности.
Судя по нарисованной цепочке — управляемая сборка, содержащая биндинги к нативному коду здорово зависит от используемого компилятора С++, точнее от результата компиляции. С++ является кроссплатформенным языком, но под каждую платформу собираются отдельные модули. Из этого следует, что придется собирать биндинги отдельно под каждую платформу.
Или я что-то неправильно понимаю?

[@kekekeks]

Вы невнимательно читали. Метаинформация содержит только типы и порядок полей и методов класса, конкретное их расположение в памяти вычисляется в рантайме на основании правил для ABI конкретного компилятора.

[@ganouver]

А как в рантайме определяются правила обращения к нативной библиотеке? в нативных dll где-то хранится информация о компиляторе?

[@kekekeks]

Скорее всего методом перебора по декорированным именам функций. Компиляторы с одинаковыми методами декорирования совместимы и по ABI, как ни странно.

[@FeoOne]

Почему в статье нет ни слова о managed C++?

[@kekekeks]

Потому что он
1) устарел и заменён C++/CLI
2) не работает нигде окромя форточек

[@novoselov]

Неплохо бы продемонстрировать процесс на простом примере. Раньше как-то не было необходимости ставить mono под cygwin под windows, все примеры по сборке достаточно старые и противоречивые.

[@kekekeks]

Вообще говоря CXXI работает и на .NET FW, просто ABI студийного компилятора C++ пока не поддерживается, сами либы нужно собирать под cygwin. А примеры есть на GitHub.

[@Gorthauer87]

А зачем cygwin? Не проще нативный MSYS взять?

[@OCTAGRAM]

Идея напоминает SWIG