visual c++ - studio - ¿Aún se usa MFC para un nuevo desarrollo(con cualquier volumen de material)?
microsoft (7)
El lanzamiento de MFC Feature Pack (uno o dos años atrás, iirc) fue la mayor extensión de MFC desde hace 10 años y dio un nuevo impulso al desarrollo de MFC. Supongo que muchas empresas decidieron mantener sus aplicaciones heredadas, impulsarlas y delevelop nuevas aplicaciones en su base.
Para mí (como alguien que tiene que mantener una aplicación MFC grande), el problema más grande es el desarrollo decreciente y el soporte de componentes (de Microsoft y de terceros) en lugar de MFC. Por ejemplo, trasladar a 64 bits no es fácil si se ensamblan muchos componentes Active-X de 32 bits puros y sin soporte en la aplicación.
Nunca he sido un gran fan de MFC, pero ese no es realmente el punto. Leí que Microsoft lanzará una nueva versión de MFC en 2010 y realmente me pareció extraño: pensé que MFC estaba muerto (sin malas intenciones, realmente lo hice).
¿El MFC se usa para nuevos desarrollos? Si es así, ¿cuál es el beneficio? No podía imaginar que tuviera algún beneficio sobre algo como C # (o incluso solo c ++ usando Win32 APIs para el caso).
Existen ventajas al mantenerse alejado del código administrado (tal vez está escribiendo una UI de controlador o haciendo COM).
Eso y hay toneladas de código MFC por ahí. Tal vez trabajas para la Compañía X y necesitas usar una de las miles de millones de DLL que han estado escribiendo durante los últimos doce años.
Hay un montón de código por ahí usando MFC. Veo estas preguntas todo el tiempo, esto todavía se usa, la respuesta es sí. Trabajo en una organización muy grande que aún emplea a cientos de personas que escriben en cobol. Si alguna vez se ha utilizado en la empresa, seguirá utilizándose hasta que no haya más hardware para admitirlo, entonces alguna empresa le pagará a alguien para que escriba un emulador para que el código antiguo siga funcionando.
La armada todavía usa naves con computadoras con núcleos magnéticos para memoria y estoy seguro de que tienen gente para trabajar en ellas. La tecnología una vez creada nunca puede ser compatible. Es un poco el caso de Deus ex machina, donde las grandes organizaciones no están completamente seguras de lo que hace su sistema y tienen un sentido tan primordial de miedo a poner a la empresa de rodillas que no desean probar sus nuevas tecnologías (por cierto le pagamos a IBM por el mejor soporte posible en OS2).
También mfc es una solución perfectamente aceptable para el desarrollo de Windows, dado que es un modelo de objetos que envuelve la API del sistema, que es prácticamente todo lo que la mayoría de la gente obtiene de .net.
Como un apéndice y dado que esta pregunta merece una recompensa, esta es una cita de MS con respecto a mfc en VS 11
En cada lanzamiento, necesitamos equilibrar nuestra inversión en las diversas áreas del producto. Sin embargo, seguimos creyendo que MFC es la biblioteca con más funciones para crear aplicaciones nativas de escritorio. Estamos totalmente comprometidos a apoyar y mantener MFC con un alto nivel de calidad. Aquí hay una breve lista de algunos de los problemas que arreglamos en MFC para Visual Studio 11:
Aquí está el link si quieres leer la publicación completa
Hice un proyecto el año pasado basado en MFC. No estoy seguro de por qué se eligió MFC, pero fue adecuado para hacer una interfaz gráfica de usuario 3D virtual -un sistema de seguridad de administración de edificios- con una velocidad de actualización de 10 fotogramas por segundo para computadoras basadas en win32 que datan de mediados de la década de 1990 . El ejecutable (que requiere solo DLL del sistema win32) es inferior a 400 K, lo que no es un logro fácil con las herramientas modernas.
La frescura no tiene en cuenta la elección de la tecnología para un nuevo sistema. Sí, si eres un estudiante o quieres jugar, elige lo que quieras.
Pero en el mundo real, cada tecnología tiene ventajas y desventajas. Hace un año, uno de los equipos comenzó un nuevo proyecto, se decidió que se realizaría en MFC. La razón es muy simple: tienen que usar Windows Api mucho para operaciones de bajo nivel con la impresora, Internet Explorer y Dios sabe qué más.
C # no estaba siquiera en el juego, la decisión se tomó entre MFC y QT, ambos tenían la funcionalidad necesaria, ambos podían integrar fácilmente la funcionalidad de bajo nivel, la única diferencia era que algunos miembros del equipo ya tenían experiencia en MFC, por lo que no tiene que perder tiempo y dinero con entrenamientos.
Supongamos que eligen C # y WPF:
-1 Debe envolver todos los códigos nativos de C ++ y ASM en una DLL (esto puede ser doloroso, en lugar de codificar los wrappers de escritura).
-1 Probablemente necesites dos equipos ahora, uno para la interfaz de usuario para las cosas winapi. Es muy poco probable que encuentres mucha gente capaz de escribir tanto C # como winapi. Estoy de acuerdo en que, de cualquier manera, necesitas que alguien haga bonita la interfaz (los programadores suelen apestar y cuestan más), pero al menos con código C ++, no hay más tiempo de espera entre dos equipos, necesitas una modificación ui, no hay problema. Tienes que esperar al diseñador de la interfaz de usuario, lo hará bonito más tarde.
+1 Puedes escribir el código de UI en C # y WPF, digamos que el desarrollo de la interfaz de usuario es más rápido, pero la UI es solo 1/4 del proyecto, por lo que la ganancia total es probablemente muy pequeña.
-1 Degradación del rendimiento: por cada operación pequeña que no se puede hacer en C #, se llama a una DLL externa (este es un problema menor ya que el programa se ejecuta en 8 GB RAM Quad Cores).
Por lo tanto, en conclusión: MFC se sigue utilizando para nuevos desarrollos porque los requisitos y los costos determinan la tecnología para un proyecto y sucede que el MFC es el mejor en algunos casos.
MFC ha sido actualizado con cada versión de Visual Studio. Simplemente no es el elemento principal del título.
En cuanto a nuevos desarrollos, sí. Todavía se usa y seguirá siéndolo (aunque yo, como tú, prefiero no hacerlo). Muchas organizaciones tomaron la decisión tecnológica hace años y no tienen motivos para cambiar.
Sin embargo, creo que estás hablando de tiendas bien establecidas, personas con más interés en mantener / mejorar lo que se ha escrito en lugar de estar a la vanguardia.
MFC se sigue utilizando para algunos desarrollos nuevos y para muchos desarrollos de mantenimiento (incluido el interior de Microsoft).
Si bien puede ser un poco más lento que utilizar la API de Win32 directamente, la pérdida de rendimiento es realmente pequeña, rara vez tanto como un porcentaje completo. Usando .NET, la pérdida de rendimiento es considerablemente mayor (en mis pruebas, raramente menos del 10%, con un 20-30% siendo típico, y aún más alto para cálculos intensos. Solo por ejemplo, tengo un programa que realiza el cálculo de Eigenvector / Eigenvalue en arreglos bastante grandes. Mi versión original con C ++ y MFC ejecuta un caso de prueba en poco menos de un minuto en nuestra máquina de prueba estándar. Algunos de mis compañeros de trabajo decidieron que sería genial implementarla nuevamente en C #. Su versión demora casi tres minutos en la misma máquina (cuatro núcleos, 16 gigas de RAM, así que no, hardware "heredado"). Admitiré que no he revisado su código demasiado de cerca, así que tal vez podría mejorarse, pero están codificadores decentes por lo que una mejora de 3: 1 me parece poco probable.
Con MFC, también es fácil pasar por alto el marco y usar la API Win32 directamente cuando / si lo desea. Con .NET, puede usar P / Invoke para eso, pero es bastante doloroso en comparación.