Comments 18
C++/CLI разве не решает эту проблему проще?
Если написание glue-кода вручную и наличие в итоговой сборке native-кода, привязанного к архитектуре процессора и неработающего нигде кроме Windows, проще, то да.
В любом случае откомпилированная библиотека на C++ будет привязана к архитектуе процессора и в ней будет native код.
Я не предлагаю писать все на C++/CLI, но налаживать на нем мосты довольно удобно.
Я не предлагаю писать все на C++/CLI, но налаживать на нем мосты довольно удобно.
основной вопрос здесь не в написании байндингов, а в их автоматической генерации.
примерно такой же подход использует проект SharpDX.
API генерируется напрямую из заголовочных файлов DirectX SDK.
примерно такой же подход использует проект SharpDX.
API генерируется напрямую из заголовочных файлов DirectX SDK.
Лично я настроен скептично. Ну то есть я верю, что они допишут это всё и оно даже будет работать. Мне не нравится идеология. Люди, которые осознанно решают использовать из C# кода классы C++ делают это по вполне понятным причинам: им не хватает производительности или управляемости или ручного управления памятью. Потому они садятся, и пишут руками на С++ все плохо реализуемые в С# вещи (включая взаимодействие С# и С++ кода). А тут этот значительный и серьёзный кусок за них сгенерит какая-то непонятная хрень. Ну и о каком контроле управляемости\производительности\памяти может идти речь?
Люди, которые осознанно решают использовать из C# кода классы C++ делают это по вполне понятным причинам: им не хватает производительности или управляемости или ручного управления памятью.Эм. Есть тонны готового, работающего и протестированного кода на C++. Зачем его переписывать на шарп? Возьмите то же Qt — переписать всё это на шарп да ещё и так, чтобы работало на всех поддерживаемых Qt платформах не представляется возможным. Таким образом CXXI — главным образом инструмент для создания биндингов к готовым библиотекам, а не смешанных приложений.
Идея занятная, но, честно говоря, я не очень понял восторгов насчет кроссплатформенности.
Судя по нарисованной цепочке — управляемая сборка, содержащая биндинги к нативному коду здорово зависит от используемого компилятора С++, точнее от результата компиляции. С++ является кроссплатформенным языком, но под каждую платформу собираются отдельные модули. Из этого следует, что придется собирать биндинги отдельно под каждую платформу.
Или я что-то неправильно понимаю?
Судя по нарисованной цепочке — управляемая сборка, содержащая биндинги к нативному коду здорово зависит от используемого компилятора С++, точнее от результата компиляции. С++ является кроссплатформенным языком, но под каждую платформу собираются отдельные модули. Из этого следует, что придется собирать биндинги отдельно под каждую платформу.
Или я что-то неправильно понимаю?
Почему в статье нет ни слова о managed C++?
Неплохо бы продемонстрировать процесс на простом примере. Раньше как-то не было необходимости ставить mono под cygwin под windows, все примеры по сборке достаточно старые и противоречивые.
Вообще говоря CXXI работает и на .NET FW, просто ABI студийного компилятора C++ пока не поддерживается, сами либы нужно собирать под cygwin. А примеры есть на GitHub.
А зачем cygwin? Не проще нативный MSYS взять?
Идея напоминает SWIG
Sign up to leave a comment.
CXXI: Мост между мирами C# и C++