2009-02-19 10 views
10

Estoy interesado en conocer la experiencia de las personas con la incrustación mono (implementación de fuente abierta de .NET) en una aplicación C/C++. ¿Cómo es distribuir tal aplicación y cuáles son las dependencias? He probado en OS X y mono viene como un gran marco (cientos de MB). ¿Los usuarios de mi aplicación necesitan este gran marco o se puede desmontar o compilar todo en el ejecutable principal?Incrustación: mono vs lua

Anteriormente tengo experiencia en incrustar Lua en una aplicación C++, y eso funciona muy bien porque puedo vincular estáticamente todo el intérprete lua con mi ejecutable principal. Entonces no tengo dependencias externas. ¿Es posible hacer algo similar con mono?

¿Alguna gente Lua aquí que pueda comentar cómo encontraron mono en comparación con Lua?

PD: Por incrustación me refiero a una aplicación C++ que inicializa un entorno mono y carga un ensamblado .NET y lo ejecuta y luego permite la comunicación entre el código C# en ensamblaje y los métodos C++ en el ejecutable principal.

Respuesta

6

Probablemente también deba echar un vistazo a la página Small Footprint de Mono que describe cómo puede incrustar un tiempo de ejecución más pequeño. Diablos, lo hacen ellos mismos con Moonlight.

Espero que ayude.

+0

Gracias. Si entiendo correctamente, ¿es mscorlib.dll y el JIT lo único que se requiere para obtener una incrustación mono? ¿Hay alguna forma de vincular estáticamente mscorlib.dll? –

+0

Mono le permite vincular completamente estáticamente su código, por lo que probablemente ni siquiera necesite el JIT. Eche un vistazo a la implementación de su iPhone. –

2

Esta es una pregunta de hace 2 años. Entonces la situación puede volverse diferente ahora.

Para mí, el punto más importante fue GC. Integré Lua para aplicaciones interactivas y juegos, porque se requiere GC incremental. Actualmente Lua 5.1 tiene GC incremental preciso, pero no pude encontrar ninguna prueba de GC incremental o precisa en Mono. Así que la memoria se fugará (¡incluso es muy pequeña!), Y las aplicaciones tendrán problemas intermitentes.

La gente dice pausa GC puede ser resuelto mediante la regulación de algunos parámetros y puesta en común de los objetos, pero como ya he experimentado, nunca se ser resuelto sin ningún tipo de carga GC distribución en el tiempo enfoque en GC. Generational GC es uno de algoritmo de distribución, pero es demasiado rudo y casi no útil.

Porque no puede controlar el patrón de vida útil ni reutilizar la instancia agrupando los objetos utilizados en el código que no es el suyo. (como la biblioteca de clases básica)

Así que no recomiendo la plataforma C# (Mono o .NET, al menos todavía) para aplicaciones interactivas/(suaves) en tiempo real.


Editar

No sé si alguna incrementales/GC concurrente acercado se presenta en Mono o .NET. Si puede estar seguro de que ofrecen el tipo de GC, por supuesto, está bien usar :)

+2

Incluso con más de 2000 juegos integrados en Mono en iOS App Store? –

+0

@Dave ¿Qué tal el número de juegos en C/C++? :) El número no prueba la presencia de GC incremental. Si no necesita interactividad seria, puede optar por GC antiguo. Pero si a sus usuarios les importa incluso un tiempo de pausa muy pequeño, lo lamentarán. – Eonil

+0

Creo que esto no tiene sentido. Si otros pueden hacer un juego en Mono, su requisito de tener un 'GC incremental' es discutible. –