¿Hay alguna ventaja importante de C++/CLI administrado sobre C#. Definitivamente no es la sintaxis supongo que el siguiente código en C++/CLI es muy fea,C++/CLI: Ventajas sobre C#
C++/CLI código:
[Out]List<SomeObject^>^% someVariable
de comparación con C# Código:
out List<SomeObject> someVariable
Sólo por curiosidad, ¿hay una sintaxis aún más fea en C++/CLI en comparación con el anterior.
Es casi exclusivamente un lenguaje de interoperabilidad, tanto para permitir el código .Net para acceder a bibliotecas heredadas de C++, como para bases extendidas (nativas) de códigos C++ con acceso a bibliotecas .Net (y algunas variaciones sobre estos temas).
Si bien es posible escribir aplicaciones de pleno derecho exclusivamente en C++/CLI, y que incluso le da un lenguaje no disponibles en C++ puro (como la recolección de basura), dudo que haya muchas personas que realmente lo haría hacer esto. Si ya se está alejando de C++ puro y no tiene el objetivo de la interoperabilidad con .Net probablemente haya opciones más naturales (como D o Scala, por ejemplo, dependiendo de la dirección en la que desee ingresar).
Del mismo modo, pasar de C# puro a C++/CLI podría aportar las ventajas de las plantillas C++, pero es raro que esta necesidad lo lleve a dar ese paso.
La ventaja de C++ administrado es que es fácil mezclar código administrado y no administrado. Pero si se administrará la totalidad (o casi la totalidad) de su código, definitivamente se debe usar C# (y todavía puede usar invoking unmanaged code from C# usando el DllImport attribute).
La interoperabilidad más fácil con el código C++ nativo es la única ventaja.
Si se trata de una gran ventaja es subjetiva.
A menos que desee mezclarse con el código C++ nativo existente, probablemente esté mucho mejor con C#.
Buena respuesta. Pero no es realmente subjetivo, es una gran ventaja si (y solo si) no tiene más remedio que lidiar con el código nativo existente. – OregonGhost
Todavía es subjetivo. Si lo que necesita es usar una DLL existente, puede elegir interoperar con el código existente usando C# y usando P/Invoke. Si se trata de una ventaja "importante" o una ventaja "menor" para tener la interoperabilidad más fácil frente a una ventaja "importante" o una ventaja "menor" para tener C#, depende completamente de la persona que hace la pregunta. –
P/Invocar con librerías C++ existentes es casi imposible ... – Milan
Usando C++/CLI es mucho más fácil de interactuar con C++ nativo código
sólo apareció a C++ \ cli cuando se tiene que, si se puede cumplir con el requisito usando C#, ¿por qué molestarse en ir C++ \ cli
En general, creo que la principal ventaja de C++/CLI es simplemente familiaridad para los desarrolladores de C++. Si no vienes de un fondo de C++, entonces usa C#.
Creo que no es así. Vengo de un fondo C++ (mezclado con Java y Delphi), y C# fue tan simple de entender. No hay necesidad de C++/CLI solo por familiaridad. Tuve suerte de alejarme de la sintaxis de C++ :) – OregonGhost
Interesante, ha pasado un tiempo desde que hice C++ pero asumí que la sintaxis de C++/CLI sería más familiar que C#, ¡pero supongo que no! –
se me ocurre 3 razones principales para utilizar C++/CLI:
aplicaciones C++ no administrados no necesitan un marco para funcionar, C# sólo se ejecutará en máquinas con el marco dotnet 1, 2, 3 o 4. Es sorprendente cuántas máquinas siguen corriendo sin que éstas marco.
Siendo un programador predominantemente C#, me encontraba teniendo que usar C++/CLI con un poco de dolor. Sin embargo, como lenguaje de interoperabilidad, EXCEDE mucho más que C# por tener que trabajar con código nativo. El C++/CLI IDE en Visual Studio carece de muchas características en el sabor C#.
En general, tiene su lugar y seguirá siendo viable mientras exista código nativo. No me gustaría tener que crear aplicaciones de WinForm desde cero con C++/CLI IDE si no fuera necesario.
Ser capaz de utilizar archivos de encabezados nativos directamente es una gran ventaja, pero no la única.
La semántica de la pila es mucho mejor que cualquier cosa C# tiene que ofrecer para la gestión IDisposable. C++/CLI tiene una sintaxis uniforme para gestionar correctamente las variables que son IDisposable y aquellas que no lo son, como variables locales y como campos de miembros. Comparación:
ref class MyClass
{
FileStream fs;
}
vs
class MyClass : IDisposable
{
FileStream fs;
void IDisposable.Dispose() { Dispose(true); }
~MyClass() { Dispose(false); }
public virtual void Dispose(bool disposing) { if (disposing) fs.Dispose(); }
}
Ahora que el lenguaje está mirando feo?
Luego están las plantillas, interior_ptr, #define, exportaciones nativas de DLL, puntero a miembro, y probablemente varias otras cosas que he olvidado.
Acepto, excepto #define. Desde mi punto de vista, su uso inmenso e indiferente en muchos proyectos es un PITA. – Alex
CLI/C++ tiene muchas ventajas sobre C#.
Odio tener que confiar en GC para llegar a un objeto atascado en el gen 2. Dios sabe cuándo será lanzado desde el montón administrado.
Puedo agregar para apoyar esto. En un proyecto anterior tuve que escribir una interfaz entre una aplicación de servicio web C# asmx y un middleware de IBM que solo tenía una biblioteca api de C++ (no una DLL sino una lib estática). C++/CLI fue la única opción para crear este puente. – softveda
Una implementación D .Net está en proceso. Puede ser que, en el futuro cercano, D pueda interoperar con .Net. – dsimcha
@dsimcha - eso sería genial – philsquared