Nunca he sido un gran fan de MFC, pero eso no es realmente el punto. He leído que Microsoft es debido a la liberación de una nueva versión de MFC en el 2010 y la verdad es que me pareció extraño – pensé MFC estaba muerto (sin mala intención, realmente lo hizo).

Es MFC es utilizado para nuevos desarrollos? Si es así, ¿cuál es el beneficio? Yo no podía imaginar tener ningún beneficio a través de algo como C# (o incluso sólo de c++ utilizando las Api de Win32 para esa materia).

  • Esta pregunta no parece ser muy diferente de su última (stackoverflow.com/questions/2269860/…). Usted debe editar preguntas en lugar de reasking ellos en formas ligeramente diferentes.
  • La pregunta que he creado antes de que se basa en la subjetiva aversión de MFC, esta pregunta es la averiguación de MFC relevancia en el presente. Yo ignoraba que podía editar la otra pregunta (después de que estaba cerrado), que fue mucho menos pensado. También estoy en el proceso de eliminación de que se trate.
InformationsquelleAutor NTDLS | 2010-02-16

7 Comentarios

  1. 24

    Hay un montón de código por ahí el uso de MFC. Veo a estas preguntas todo el tiempo es este todavía se utiliza es que todavía se utiliza la respuesta es sí. Yo trabajo en una organización muy grande que todavía emplea a cientos de personas que escriben en cobol. Si alguna vez ha sido utilizado en la empresa que va a continuar hasta que no hay más de hardware que lo soporte, a continuación, algunos de la compañía tendrá que pagar a alguien para escribir un emulador, así que el viejo código seguirá funcionando.

    La marina todavía usa barcos con equipos con núcleos magnéticos para la memoria y estoy seguro de que tienen las personas para trabajar en ellos. La tecnología una vez creado nunca pueden no ser compatibles. es un poco el caso de Deus ex machina, donde las grandes organizaciones no estás completamente seguro de lo que su sistema de hacer y tienen un fuerte sentimiento de miedo, de incorporar a la empresa para que sus rodillas no tienen ningún deseo de probar nuevas fangled tecnologías(por CIERTO pagamos IBM para la mejor asistencia en OS2).

    También mfc es perfectamente aceptable que la solución para el desarrollo de windows dado que es un modelo de objetos que se ajusta a las API del Sistema que es casi todo lo que la mayoría de la gente a salir de .net.


    Como un apéndice, y dado que esta pregunta es para una recompensa esta es una cita de MS respecto de mfc en el VS 11

    En cada lanzamiento que debemos equilibrar nuestra inversión en las diferentes áreas del producto. Sin embargo, todavía creemos que el MFC es el más completo de la biblioteca para la construcción de aplicaciones de escritorio nativas. Estamos plenamente comprometidos a apoyar y mantener la MFC en un alto nivel de calidad. He aquí una breve lista de algunos de los problemas que se fija en MFC de Visual Studio 11:

    Aquí es el enlace si quieres leer el post completo

  2. 18

    Frialdad no es un factor en la elección de la tecnología para un nuevo sistema. Sí, si usted es un estudiante o quieren jugar alrededor de usted elegir el que prefiera.

    Pero en el mundo real cada tecnología tiene sus ventajas y sus inconvenientes. Hace un año uno de los equipos en marcha un nuevo proyecto, se decidió que se llevará a cabo en MFC.
    La razón es muy simple: tienen que usar la api de windows de una gran cantidad de operaciones de bajo nivel con la impresora, internet explorer y dios sabe qué más.

    C# ni siquiera estaba en el juego, la decisión fue tomada entre MFC y QT, ambos tenía la funcionalidad necesaria, tanto podría integrar fácilmente el bajo nivel de funcionalidad, la única diferencia es que algunos miembros del equipo que ya había MFC experiencia, para que no tengan que perder tiempo y dinero con los entrenamientos.

    Supongamos que C# y WPF:


    -1 Se tiene que envolver a todos los nativos de C++ y ASM código en un archivo DLL (ouch esto puede ser doloroso, en lugar de la codificación de escribir envolturas).


    -1 Usted probablemente necesitará dos equipos, uno para la interfaz de usuario uno para la winapi cosas. Es muy poco probable que usted encontrará una gran cantidad de gente capaz de escribir tanto en C# y winapi cosas. Convino en que, de cualquier manera que usted necesita a alguien para hacer que la interfaz bastante (los programadores suelen aspirar a este y también más caros) pero al menos con C++ sólo el código, no hay más tiempo de espera entre dos equipos, la necesidad de una interfaz de usuario modificación, no hay problema, no tengo que esperar para que el diseñador de interfaz de usuario, que será bastante más tarde.


    +1 Se puede escribir el código de interfaz de usuario en C# y WPF, digamos que el desarrollo de la IU es más rápido, pero la interfaz de usuario es sólo 1/4 del proyecto, por lo que la ganancia total es probablemente muy pequeño.

    -1 degradación del Rendimiento: para cada operación pequeña no se puede hacer en C# que llamar a una DLL externo (este es un tema menor, ya que el programa se ejecuta en 8GB de RAM Quad Cores).

    Así que en conclusión: MFC todavía se utiliza para el desarrollo de nuevos debido a los requisitos y los costos de decidir la tecnología para un proyecto y se da la circunstancia de que la MFC es el mejor en algunos casos.

    • Hmmm…Muy buena explicación! Quiero empezar a aprender C++ desarrollo de GUI. Debo aprender MFC o QT? ¿Qué dicen ustedes? Me ofreció la recompensa. Por favor, dame una buena sugerencia para obtener una aceptación. Puedo utilizar MFC/QT tanto para Dx/OpenGL desarrollo de juegos y aplicaciones controladas por Datos?
    • En general me parece Qt se utiliza más que el MFC, ya que es multiplataforma y libre. En uno de los proyectos usado en un dispositivo integrado que ejecuta una costumbre distro de Linux. Yo nunca uso Dx/OpenGl con MFC o QT, pero ya que Dx/OpenGL sólo requieren de una ventana de su programa, no veo razón para que no funcione con MFC y QT.
    • Dx/OpenGl es algo que yo hice en la universidad y para la diversión, así que no tengo ningún ‘real’ de la experiencia con ella, pero recuerdo que había algunos marcos como «irrlicht» que ofrece un montón de funcionalidades, incluyendo diálogos, las ventanas de la interfaz gráfica de usuario. Así que supongo que tiene más sentido utilizar un marco de este tipo si desea hacer desarrollar Dx/OpenGL.
  3. 14

    MFC se utiliza todavía para algunos nuevo desarrollo, y una gran cantidad de mantenimiento de desarrollo (incluyendo dentro de Microsoft).

    Mientras que puede ser minuciosamente lento que el uso de la API de Win32 directamente, la pérdida de rendimiento es realmente pequeño-rara vez tanto como un entero por ciento. El uso de .NET, la pérdida de rendimiento es considerablemente mayor (en mis pruebas, rara vez menos de 10%, con un 20-30%, siendo típico, y más aún para el cómputo pesado. Por ejemplo, yo tengo un programa que hace Autovector/Autovalor de cálculo bastante grandes matrices. Mi versión original con C++ y MFC se ejecuta un caso de prueba en sólo menos de un minuto en nuestro estándar de la máquina de prueba. Algunos de mis compañeros de trabajo decidió que sería genial volver a implementarlo en C#. Su versión dura casi tres minutos en la misma máquina (quad core, de 16 gigas de RAM, así que no, no «heredado» de hardware). Admito que no he mirado el código demasiado cerca, así que tal vez se puede mejorar, pero son decentes los codificadores de forma de 3:1 mejora me parece raro.

    Con MFC, también es fácil de eludir el marco y el uso de la API de Win32 directamente cuando/si quieres. Con .NET, usted puede uso P/Invoke para eso, pero es bastante dolorosa por comparación.

    • Cuánto de eso es debido a la interfaz gráfica de usuario, aunque? Es de suponer que usted está usando algo como Intel MKL de las matemáticas en ambos casos, así que lo que realmente está causando la diferencia?
    • este programa en particular no utiliza código externo en cualquiera de las rutas críticas. Si me permiten mi suena un poco engreído, Intel programadores son buenos en la optimización — pero yo soy mejor. Más en serio, una gran cantidad de Intel optimizaciones (por casualidad o de otra manera) a hacer bastante mal en procesadores AMD, lo que era inaceptable para este código.
  4. 8

    MFC ha sido actualizado con cada lanzamiento de Visual Studio. Simplemente no es la función principal elemento.

    Como para el desarrollo nuevo, sí. Todavía es usado y seguirá siendo así (aunque yo, como tú, prefiero no). Muchas organizaciones de la tecnología de la decisión de años y no tiene ninguna razón para cambiar.

    Yo creo que estás hablando de la bien establecida tiendas, aunque, a la gente con más interés en mantener /mejorar lo que se ha escrito en lugar de permanecer en la vanguardia.

  5. 8

    La liberación de la MFC Feature Pack (hace uno o dos años, si mal no recuerdo) fue la mayor extensión de MFC, ya que alrededor de 10 años y se dio un nuevo impulso a la MFC desarrollo. Supongo que un montón de empresas que decidieron mantener sus aplicaciones heredadas, les empuje hacia adelante y delevelop nuevas aplicaciones en su base.

    Para mí (como alguien que tiene que mantener una gran aplicación MFC) el mayor problema es la disminución del desarrollo y el apoyo de (de Microsoft y de terceros) componentes en lugar de MFC. Por ejemplo, es migrar a 64 bits no es fácil si un montón de viejos y no admitidos puro de 32 bits de Active-X los componentes están montados en la aplicación.

  6. 3

    Hay ventajas para mantenerse alejado de código administrado (tal vez usted está escribiendo un controlador de interfaz de usuario, o haciendo COM).

    Que y hay toneladas de MFC código por ahí. Tal vez usted trabaja para la Empresa X, y la necesidad de utilizar uno de los tropecientos archivos Dll que he estado escribiendo durante los últimos doce años.

    • Acuerdo! Soy un fan de la vieja escuela de código no administrado -, pero no estoy seguro si se puede escribir controladores mediante MFC (no estoy diciendo que uno no puede, yo no lo creía posible. Ciertamente no es un controlador de modo de núcleo).
    • Me refería controlador de la interfaz de usuario (como un «Diálogo de la Impresora» o algo). La codificación de los cuadros de diálogo en el MFC es realmente rápido.
    • Estoy mucho más acostumbrado a la creación de C++ aplicación Win32 uso básico de un editor de recursos y un WinProc de devolución de llamada – que para mí es mucho más rápido. Subjetivo, sí, pero personalmente veo poco atractivo en el uso de MFC para tales aplicaciones. Esto no me hacen derecho por cualquier medio.
    • Por supuesto escribir algo sin MFC es más lento si uno no sabe MFC. La escritura de la misma aplicación con la MFC es mucho más rápido que escribir el equivalente en win32, dado un programador competente.
  7. 2

    Hice un proyecto el año pasado basada en MFC. No estoy seguro de por qué MFC fue elegido, pero fue suficiente para hacer una virtual 3D interfaz gráfica de usuario—un edificio de administración del sistema de seguridad—con 10 fotogramas por segundo, la frecuencia de actualización de ejecutar de manera eficiente en win32 los equipos que se remonta a mediados de la década de 1990. El ejecutable (que requiere sólo el núcleo central de win32 Dll del sistema) está a menos de 400K—no es un logro fácil con las herramientas más modernas.

    • Así, el desarrollo de «el legado» de los sistemas? (No estoy siendo crítico, me gusta el legado de sistemas). Mi problema es que el archivo DLL de MFC eran ENORMES (para su tiempo) y bastante ineficaz. Así que si el tamaño o la velocidad son una preocupación ¿por qué no seguir con la Win32APIs?
    • Porque win32 es un retroceso enorme en el tiempo de desarrollo y que va a terminar de escribir contenedores para hacerlo más OO de todos modos. MFC dll no es tan enorme, y si realmente se trata de un tema todavía se puede vincular de forma estática.
    • Así dll de MFC son enormes? Supongo que usted piensa .net framework es más pequeño, piense de nuevo. También tengo curiosidad ¿cómo se puede enlazar estáticamente código de C# (para que se ejecute sin todos los .net dll)
    • No hay manera de hombre! Soy un gran ol’ fan de .la red, pero que marco es un mamut! C# es la forma en que tI tratar de ir con nuevos proyectos, pero tengo gran amor por la C/C++ en Win32… pero mucho me prefieren hacerlo sin MFC. Si me voy tengo la eficiencia en el nivel más bajo de lenguaje entiendo entonces voy como nativo como puedo.
    • Ahora .NET Core hace. Por CIERTO, esto no significó para el desarrollo de GUI…

Dejar respuesta

Please enter your comment!
Please enter your name here