Вложение: моно против Луа - PullRequest
10 голосов
/ 19 февраля 2009

Мне интересно услышать об опыте людей по внедрению mono (реализация с открытым исходным кодом .NET) в приложение C / C ++. Как это распространять такое приложение и каковы зависимости? Я протестировал на OS X и моно поставляется в виде огромного фреймворка (сотни МБ). Все ли пользователи моего приложения нуждаются в этом большом фреймворке, или его можно урезать или все скомпилировать в основной исполняемый файл.

Ранее у меня был опыт встраивания Lua в приложение C ++, и это работает очень хорошо, потому что я могу статически связать весь интерпретатор lua с моим основным исполняемым файлом. Так что у меня нет внешних зависимостей. Можно ли сделать что-то похожее с моно?

Есть ли здесь люди из Lua, которые могут прокомментировать, как они нашли моно по сравнению с Lua?

PS: Под внедрением я имею в виду приложение C ++, которое инициализирует моно-среду и загружает сборку .NET и выполняет ее, а затем обеспечивает связь между, скажем, кодом C # в сборке и методами C ++ в основном исполняемом файле.

Ответы [ 2 ]

6 голосов
/ 19 февраля 2009

Возможно, вам также стоит взглянуть на страницу Small Footprint Mono, в которой описано, как можно встроить меньшее время выполнения. Черт возьми, они делают это сами с Лунным светом .

Надеюсь, это поможет.

2 голосов
/ 22 июня 2011

Это вопрос 2 года. Так что теперь ситуация может измениться.

Для меня самым важным моментом был GC. Я добавил Lua для интерактивных приложений и игр, потому что требуется инкрементальный сборщик мусора. В настоящее время Lua 5.1 имеет точный, инкрементальный GC, но я не смог найти никаких доказательств инкрементного или точного GC на Mono. Таким образом, утечка памяти (даже очень маленькая!) И приложения будут время от времени бороться.

Люди говорят, что GC-пауза может быть решена путем настройки некоторых параметров и объединения объектов, но, как я понял, она никогда не может быть решена без какого-либо распределения GC-нагрузки со временем GC. Генеративный сборщик мусора - это алгоритм распределения, но он слишком грубый и почти бесполезный.

Поскольку вы не можете управлять шаблоном жизни или повторным использованием экземпляра, объединяя объекты, используемые в коде, но не в вашем. (например, базовая библиотека классов)

Так что я не рекомендую платформу C # (Mono или .NET, по крайней мере, пока) для интерактивных / (мягких) приложений реального времени.


Редактировать

Я не знаю, представлен ли какой-либо инкрементальный / параллельный GC в Mono или .NET. Если вы можете быть уверены в том, что они предлагают тип GC, то, конечно, его можно использовать :)

...