c# - C++ MFC vs.NET?
visual-c++ (10)
Mis colegas están usando Visual Studio 2002 y usan C ++ MFC. Estoy desarrollando en C #.
No ha habido ningún problema antes, pero ahora preguntamos a nuestros clientes si realmente deberíamos desarrollar en diferentes entornos. Mis colegas piensan (por supuesto) que debería pasar a C ++ MFC. Creo que pueden usar .NET en lugar de MFC.
¿Hay algún punto para aprender el MFC? Se siente un poco pasado de moda, ¿o estoy equivocado? ¿Cuáles son los argumentos en contra de y para .NET en comparación con MFC?
Editar:
Estamos desarrollando sistemas de procesos y aplicaciones de asistencia para la industria nuclear. La aplicación principal es un emulador que emula un sistema informático antiguo y utiliza C ++ / MFC. Es muy crítico en el tiempo, tal vez el núcleo debería seguir estando en C ++ nativo. Pero la GUI para el emulador y todas las aplicaciones circundantes no son particularmente críticas.
¿Y hay alguna razón real por la que deba reemplazar la aplicación MFC existente?
.NET usa código administrado. MFC usa código no administrado. He leído que el código no administrado se ejecuta más rápido que el código administrado. Por lo tanto, si está desarrollando código blando en tiempo real, es posible que desee utilizar un código no administrado.
Creo que hay un valor en conocer C ++ ya que el lenguaje durará mucho tiempo. Nunca se sabe cuándo puede ser necesaria la programación en C ++, y en el mercado laboral actual, tener más idiomas a su alcance solo mejora su currículum.
En cuanto a MFC , hago mi mejor esfuerzo para alejarme de eso. Es antiguo según los estándares informáticos (creo que se acerca a los 20 años), pero Microsoft todavía ve el valor de respaldarlo con nuevas versiones y paquetes de características. Desde ese punto de vista, dudo que MFC desaparezca pronto. Pero eso no significa que quiera programar con eso. La fluidez y facilidad con la que se puede programar en C # supera a los pantalones de MFC / C ++ todos los días de la semana. Threading, sockets, manipulación de cadenas, etc. - todas estas cosas son simplemente más fáciles de hacer en C # que en C ++. Además, C # /. NET es el enfoque de tecnología principal para Microsoft, y prefiero estar en ese límite que el backburner de MFC cuando se trata de desarrollo profesional.
Hay muchos pros / contras en esta elección. MFC es el viejo stand by, ha existido por años y muestra su edad. Por otro lado, todavía está bastante bien soportado y MS sigue actualizándolo para mantenerse actualizado.
El framework .Net tiene mejor soporte ya que cuenta con un equipo más grande que lo respalda y se lo ve como algo para construir nuevas partes de Windows.
Por otro lado, MFC es una gran parte del Ecosistema de Windows. Si estás programando en la plataforma, valdrá la pena tener al menos un conocimiento práctico de lo que hace MFC y cómo hacerlo cuando termines apoyando una aplicación MFC (y no te preocupes, algún día lo harás). tener una buena base sobre dónde comenzar.
He usado MFC y Windows Forms extensamente durante mucho tiempo. Soy de la industria de los videojuegos, así que he tenido que escribir muchas aplicaciones de escritorio a lo largo de los años, y antes de .net, MFC era extremadamente útil. Incluso antes de eso estaba escribiendo herramientas en Win32 puro.
MFC definitivamente tenía sus peculiaridades, pero en general le hizo la vida mucho más fácil. Fue muy fácil integrar OpenGL y Direct3D en vistas personalizadas, y una vez que te acostumbraste a escribir controles personalizados fue un pedazo de pastel. Lo mejor de todo es que pude codificar en C ++ puro, que resultó ser el idioma de mi elección. Además, encontré que MFC es muy eficiente y ágil.
Poco a poco, MFC comenzó a obtener compatibilidad con la biblioteca de control externo, en particular las bibliotecas de acoplamiento / barra de herramientas, por lo que mis herramientas, como los visores de modelos 3D y los editores de niveles, parecían bastante dulces.
La mayoría de las aplicaciones que escribí creaban la interfaz de usuario programáticamente, por lo que la herramienta de diseño de ventana / diálogo era más que adecuada para mis necesidades.
MFC 9 también es genial, especialmente con la biblioteca de control / acoplamiento Ribbon que Microsoft lanzó como parte del Feature Pack. ¡Así que todavía hay vida en el viejo perro, seguro! :)
Cuando apareció .net 1.0 encontré la transición bastante fácil, porque soportaba C ++ administrado. No fue bonito, pero dio una entrada relativamente directa al framework .net. Pero el punto de inflexión para mí vino cuando comencé a escribir herramientas que necesitaban más el Diseñador de Windows Forms, alrededor de .net 2.0. Decidí volver a empezar y aprender C #, lo cual me encantó, aunque nunca me acostumbraré a tener new () sin delete ();). Luego comencé a escribir controles de usuario, encontrando toda la experiencia muy agradable y directa. El framework .net era enorme, estaba bien soportado y, en general, me resultó más fácil hacer casi todo en C # / .net. Además, la compilación fue increíblemente rápida y la capacidad de refactorización en Visual Studio fue increíble.
La belleza de c # /. Net es que no te limita a solo escribir en código administrado. Todavía puede usar código no administrado, si el rendimiento es un problema, por ejemplo, o si necesita compartir el código entre plataformas. Por ejemplo, mis bibliotecas matemáticas están escritas en C / C ++, que pongo en bibliotecas que permiten C # para envolver / usar el mismo código, aunque eso es solo temporal. También voy a portar esas bibliotecas a C # a tiempo para que todo sea puro .net.
La última experiencia que quiero mencionar es que he estado pasando los últimos meses lejos de la programación de juegos de consola, y pasando el tiempo programando el InterWeb. He estado usando la pila de Microsoft, programando en ASP.net/C#, y tengo que decir que es muy bueno, con todo el conocimiento de C # directamente aplicable. La única curva de aprendizaje fue ASP.net, no las bibliotecas de idiomas y soporte. Con la llegada de .net 3.5 (LINQ es dulce), la vida en el framework .net con C # es encantadora.
De todos modos, no quiero convertir esto en la historia de mi vida, pero solo quería dar una breve experiencia de alguien que se ha movido a través de toda la tecnología que ha pedido. También me gustaría mencionar que es bueno para ti probar diferentes idiomas / frameworks. Llevo un año codificando para el iPhone, y he llegado a gustarme Objective-C. Es todo programación y todo está bien.
Con respecto a MFC / .net, ambos tienen sus ventajas y desventajas, y realmente no me importa el MFC en absoluto, pero en términos de seguir adelante, probablemente me quedo con C # / .net, pero por favor, por favor, por favor entender cómo funciona La única cosa de sermones que diré es comprender cómo funciona la memoria en .net, a pesar de que "todo se solucionó para ti";)
Su conocimiento de C / C ++ debe ser completamente independiente de si usa MFC o no, sigue siendo un lenguaje crítico (particularmente en la programación de videojuegos basada en consola), pero para la programación de aplicaciones de escritorio en Windows, cada vez es más difícil argumentar en contra .red. Es rápido, fácil, tiene una gran compatibilidad con herramientas, excelentes bibliotecas de terceros, una enorme comunidad en crecimiento, ahora es multiplataforma (Mono) y le permitirá moverse entre todas las tecnologías actuales / emergentes de Microsoft (ASP.net, WPF, Silverlight, WCF etc.)
Por todo esto, sin embargo, configuro Visual Studio como un entorno C ++. Algunos hábitos nunca mueren;)
Hice la transición de C ++ / MFC a C # / WinForms hace poco más de un año (tarde, lo sé;)).
Dejando a un lado las diferencias idiomáticas, será mucho más fácil hacer la transición de MFC a WinForms que al revés. Creo que definitivamente hay valor en conocer MFC si tiene la intención de ser eficaz en el mantenimiento de aplicaciones heredadas. Sin embargo:
¿Aprendería MFC desde cero (dadas las tecnologías existentes)? No, probablemente no.
¿Escribiría nuevas aplicaciones en MFC? No, probablemente no.
Las ventajas de MFC son superadas por el soporte, la flexibilidad y la facilidad de uso de .NET. Por lo que es, MFC es excelente, y estoy agradecido por la oportunidad de haber trabajado con él, me enseñó mucho . En última instancia, sin embargo, está a punto de desaparecer.
MFC y .NET se encuentran en extremos casi opuestos, cada uno completamente malo a su manera.
El uso de MFC es más o menos del orden de la vida en el naufragio en decadencia de un edificio con excedentes de la Segunda Guerra Mundial. No hay señales que adviertan sobre áreas peligrosas, y probablemente no sea inmediatamente evidente dónde encontrar agua corriente, electricidad o un inodoro que funcione, aunque todos estén allí, si sabe cómo encontrarlos. Al igual que cualquier edificio en descomposición, hay muchos agujeros en las paredes y tal, por lo que puede irse en cualquier momento que desee durante el tiempo que desee. Del mismo modo, arrastrar cosas del mundo exterior es bastante fácil, aunque depende de ti hacer el "arrastre" para lograrlo.
Usar .NET es como vivir en el set de The Truman Show . Se ajusta a la idea de una persona de cómo debería ser la vida real. Dentro de sus límites, la vida puede parecer utópica. Al final, sin embargo, es poco más que una celda de la prisión agradablemente acondicionada, y nada de lo que retrata, ya que la vida es bastante real. Toda su interacción con el mundo exterior está sujeta al capricho de un director cuyos objetivos son principalmente mejorar sus propias calificaciones; su bienestar se considera solo en la medida en que lo afecte.
A diferencia de la mayoría de las prisiones, .NET tiene una ruta de escape bien marcada (etiquetada como "P / Invocar"). Sin embargo, al igual que la ruta de escape de cualquier prisión buena, es una tubería de aguas residuales de una milla de largo. La mayoría de los residentes son conscientes de su existencia, pero casi los únicos que van allí son adolescentes que demuestran su hombría. Los pocos que lo usan realmente lo hacen solo en extrema necesidad. Aquellos de nosotros que lo consideramos necesario con demasiada frecuencia nos hemos dado cuenta de que es mejor quedarse afuera y no volver a entrar.
Editar: Dado que algunas personas quieren círculos y flechas y un párrafo en la parte posterior de cada uno para ser utilizado como evidencia en la corte: la fortaleza y debilidad de MFC es que es principalmente un envoltorio bastante fino alrededor de la API. Esa es una debilidad porque hay un buen número de agujeros en su cobertura, y porque hace relativamente poco para "suavizar" los lugares que la API en sí no encaja especialmente bien. Por ejemplo, si se implementa algo utilizando COM, generalmente se mostrará directamente en el código que lo usa. Es una fortaleza, porque es bastante fácil extender MFC para manejar áreas que no tiene de manera predeterminada, así como también omitirlo y trabajar directamente con la API cuando lo necesite. También se ha actualizado con relativa poca frecuencia, por lo que aunque actualmente puede producir aplicaciones razonablemente "modernas", ese no siempre ha sido el caso. Dada su historia, sería difícil predecir que continuará siendo el caso.
La fortaleza y debilidad de .NET es que es un envoltorio mucho más "grueso" alrededor de la API. Hace mucho más para "suavizar" las diferencias en la API, por lo que (por ejemplo) las partes que se implementan en COM no se ven / actúan de forma notablemente diferente de las partes que se implementan como llamadas directas a la función C. Desde dentro de .NET, las diferencias desaparecen. .NET es (actualmente) la tecnología favorita de Microsoft, por lo que se actualiza mucho más regularmente, y hace un mejor trabajo para garantizar que su UI siga las últimas pautas. Supongo que es mucho más probable que MFC continúe haciéndolo durante un tiempo.
La debilidad de .NET es que es mucho más difícil de omitir o ampliar. Básicamente, tu única ruta al mundo exterior es a través de P / Invoke. Incluso para pequeñas excursiones, es feo y doloroso. Tratar de usarlo con mucha frecuencia o para cualquier cosa que se acerque a una extensión importante es un ejercicio de masoquismo.
Si (casi) todo lo que escribes puede encajar dentro de lo que admite .NET, es la opción más clara. Es mucho más limpio y suave siempre y cuando permanezcas dentro de sus límites.
Si escribe código que con frecuencia necesita salir de los límites admitidos por el marco, MFC probablemente funcionará mucho mejor para usted. Con .NET, el modelo .NET se aplica a todo su programa. Con MFC, es relativamente fácil escribir programas que usan MFC para su UI, y hacer las cosas que deseen para cualquier otra cosa que MFC no admita.
No es uno contra el otro. Desde la versión 1.1, Windows Forms admite ser hospedado por clientes nativos como IE o MFC. MFC 8.0 incluyó el código de alojamiento necesario en sus clases de soporte de Windows Forms para que no tenga que escribir el suyo propio. Elija la biblioteca adecuada en función de los requisitos de su proyecto actual.
MFC es más que sus clases de contenedor GDI, sin embargo. En un momento se diseñó como el reemplazo OOP para la API Win32 subyacente, más o menos como .Net hoy. Sin embargo, MFC no impidió que la API de Win32 creciera y ahora puedo decir que las API de Win32 crecen a partir de lo que admite MFC. El número de API aumentó docenas de veces en la última década.
Windows Forms, por otro lado, estaba destinado a ser un reemplazo solo para el sistema GDI de Windows. Es el resto de las bibliotecas .NET Framework que están destinadas a reemplazar el resto de Win32, como WPF y XNA para DirectX y System.Speech para SAPI. Sin embargo, puedo ver que las API de win32 crecen a partir de lo que .Net puede mantener sin aumentar significativamente el tamaño de descarga en unos pocos años.
Por lo tanto, Windows Forms no puede hacer todo lo que MFC puede hacer, está diseñado para hacer más fácil la RAD basada en GDI + y puede incluir lo que MFC no puede hacer. Sin embargo, las Formas de Windows basadas en GDI + van cuesta abajo ya que Microsoft se reenfocó en WPF, mientras que MFC revivió en función de la solicitud del consumidor. Si está diseñando para futuras aplicaciones, es posible que desee tener esto en cuenta.
Una buena característica que proporciona MFC es el marco de documento / vista (documento único o documentos múltiples) que aún no tenía la equivalencia en .NET. Esta característica puede ser muy útil y útil cuando necesite crear una aplicación que funcione como Word de Microsoft. Ayuda a separar el modelo de datos de la vista que desea representar a los usuarios. Creo que la mayoría de la gente saltará al lado de .NET para siempre una vez que se haya implementado esta función. (¿Microsoft está trabajando en esto o al menos tiene planes para trabajar en esto?)
¿Cuál es el problema que estás buscando resolver? Supongamos que conoce tanto C ++ / MFC como C # /. NET por igual. ¿Qué conjunto de herramientas te permitirá construir y mantener mejor? (Mejor es subjetivo, pero de nuevo depende de tus objetivos)
A menos que haga mucho trabajo con API nativas que no están disponibles en .NET, iré con .NET por mucho. C ++ es un excelente lenguaje y nada le impide codificar en Managed C ++ para mantener el marco de .NET y la administración de memoria.
En comparación, mi observación es que el marco de MFC es muy complicado y difícil de manejar en comparación con los formularios de Windows .NET.
El código no administrado no se ejecuta necesariamente más rápido, depende del código escrito y el que escribe el código. He leído algunos informes sofisticados de referencia (fuente, Code Project) y C # venció C ++ en algunos aspectos, C ++ ganó en otros. Depende de su campo: escribo software para Flight Simulators, por lo tanto, necesito un entorno no administrado. Si está haciendo una aplicación GUI, C # puede ser la mejor opción. Para la programación de bajo nivel de palanca, C ++ puede devolver mejores resultados. No he notado ninguna diferencia de velocidad entre C ++ y C # en las operaciones normales, pero soy fan de C ++ por su portabilidad nativa y C # por su facilidad.