2009-02-19 8 views
10

Je suis intéressé par l'expérience des gens avec l'intégration de mono (implémentation open source de .NET) dans une application C/C++. Comment distribuer une telle application et quelles sont les dépendances? J'ai testé sur OS X et le mono est un énorme framework (des centaines de Mo). Est-ce que les utilisateurs de mon application ont tous besoin de ce grand framework ou peuvent-ils être effacés ou tout être compilé dans l'exécutable principal? J'ai déjà eu de l'expérience avec l'intégration de Lua dans une application C++, et cela fonctionne très bien parce que je peux lier statiquement l'interpréteur lua entier avec mon exécutable principal. Donc je n'ai pas de dépendances externes. Est-il possible de faire quelque chose de similaire avec mono?Incorporation: mono vs lua

Y a-t-il des gens Lua ici qui peuvent commenter comment ils ont trouvé mono par rapport à Lua? PS: En intégrant je veux dire une application C++ qui initialise un environnement mono et charge un assembly .NET et l'exécute, puis permet la communication entre le code C# dans l'assembly et les méthodes C++ dans l'exécutable principal.

Répondre

6

Vous devriez également jeter un coup d'œil à la page Small Footprint de Mono qui décrit comment vous pouvez intégrer un temps d'exécution plus petit. Heck, ils le font eux-mêmes avec Moonlight.

J'espère que cela aide.

+0

Merci. Si je comprends bien, est-ce que mscorlib.dll et le JIT sont les seules choses qui sont nécessaires pour obtenir mono intégré? Y at-il un moyen de lier statiquement mscorlib.dll? –

+0

Mono vous permet de lier complètement votre code de manière statique, donc vous n'avez probablement même pas besoin du JIT. Jetez un oeil à leur implémentation iPhone. –

2

Ceci est une question vieille de 2 ans. Donc, la situation peut devenir différente maintenant.

Pour moi, le point le plus important était GC. J'ai intégré Lua pour les applications interactives et les jeux, car GC incrémental requis. Actuellement, Lua 5.1 a un GC précis et incrémental, mais je n'ai trouvé aucune preuve de GC incrémental ou précis sur Mono. Donc, la mémoire va fuir (même si elle est minuscule!), Et les applications vont se débattre par intermittence.

Les gens dit pause GC peut être résolu en réglant certains paramètres et des objets mise en commun, mais comme je l'ai connu, il ne être résolu sans aucune charge la distribution de GC au fil du temps approche en GC. Generational GC est l'un des algorithmes de distribution, mais il est trop approximatif et presque inutile. Parce que vous ne pouvez pas contrôler le modèle de durée de vie ou réutiliser l'instance en regroupant les objets utilisés dans le code qui n'est pas le vôtre. (comme la bibliothèque de classes de base)

Je ne recommande donc pas la plate-forme C# (Mono ou .NET, au moins pour le moment) pour les applications interactives/(soft) en temps réel.


Modifier

Je ne sais pas si GC approché incrémentielle/concurrent est présenté sur Mono ou .NET. Si vous pouvez vous assurer qu'ils offrent le type de GC, bien sûr, il est bon d'utiliser :)

+2

Même avec plus de 2000 jeux construits sur Mono dans l'App Store iOS? –

+0

@Dave Que diriez-vous du nombre de jeux en C/C++? :) Le nombre ne prouve pas la présence de GC incrémental. Si vous n'avez pas besoin d'interactivité sérieuse, vous pouvez opter pour l'ancien GC. Mais si vos utilisateurs s'inquiètent du temps de pause, vous le regretterez. – Eonil

+0

Je pense que c'est inutile. Si d'autres peuvent faire un jeu en Mono, votre exigence d'avoir un «GC incrémental» est discutable. –