C++
Mono & Moonlight
C#
Comments 18
+2
Если написание glue-кода вручную и наличие в итоговой сборке native-кода, привязанного к архитектуре процессора и неработающего нигде кроме Windows, проще, то да.
+2
В любом случае откомпилированная библиотека на C++ будет привязана к архитектуе процессора и в ней будет native код.

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

Возможно, если эти ребята побороли эту проблему, то штука на самом деле полезная.
0
основной вопрос здесь не в написании байндингов, а в их автоматической генерации.
примерно такой же подход использует проект SharpDX.
API генерируется напрямую из заголовочных файлов DirectX SDK.
image
+2
Лично я настроен скептично. Ну то есть я верю, что они допишут это всё и оно даже будет работать. Мне не нравится идеология. Люди, которые осознанно решают использовать из C# кода классы C++ делают это по вполне понятным причинам: им не хватает производительности или управляемости или ручного управления памятью. Потому они садятся, и пишут руками на С++ все плохо реализуемые в С# вещи (включая взаимодействие С# и С++ кода). А тут этот значительный и серьёзный кусок за них сгенерит какая-то непонятная хрень. Ну и о каком контроле управляемости\производительности\памяти может идти речь?
0
Люди, которые осознанно решают использовать из C# кода классы C++ делают это по вполне понятным причинам: им не хватает производительности или управляемости или ручного управления памятью.
Эм. Есть тонны готового, работающего и протестированного кода на C++. Зачем его переписывать на шарп? Возьмите то же Qt — переписать всё это на шарп да ещё и так, чтобы работало на всех поддерживаемых Qt платформах не представляется возможным. Таким образом CXXI — главным образом инструмент для создания биндингов к готовым библиотекам, а не смешанных приложений.
+1
Идея занятная, но, честно говоря, я не очень понял восторгов насчет кроссплатформенности.
Судя по нарисованной цепочке — управляемая сборка, содержащая биндинги к нативному коду здорово зависит от используемого компилятора С++, точнее от результата компиляции. С++ является кроссплатформенным языком, но под каждую платформу собираются отдельные модули. Из этого следует, что придется собирать биндинги отдельно под каждую платформу.
Или я что-то неправильно понимаю?
0
Вы невнимательно читали. Метаинформация содержит только типы и порядок полей и методов класса, конкретное их расположение в памяти вычисляется в рантайме на основании правил для ABI конкретного компилятора.
0
А как в рантайме определяются правила обращения к нативной библиотеке? в нативных dll где-то хранится информация о компиляторе?
0
Скорее всего методом перебора по декорированным именам функций. Компиляторы с одинаковыми методами декорирования совместимы и по ABI, как ни странно.
0
Потому что он
1) устарел и заменён C++/CLI
2) не работает нигде окромя форточек
0
Неплохо бы продемонстрировать процесс на простом примере. Раньше как-то не было необходимости ставить mono под cygwin под windows, все примеры по сборке достаточно старые и противоречивые.
0
Вообще говоря CXXI работает и на .NET FW, просто ABI студийного компилятора C++ пока не поддерживается, сами либы нужно собирать под cygwin. А примеры есть на GitHub.
Only those users with full accounts are able to leave comments. , please.