visual studio c++ visual-c++ mfc atl

c++ - studio - ¿Cuál es la diferencia fundamental entre MFC y ATL?



mfc c++ (3)

ATL es un conjunto de clases destinadas a simplificar la implementación de objetos COM.

Puede usarlo sin MFC. En mi trabajo, utilizamos ATL para exponer las interfaces COM al código computacional. No hay una GUI involucrada, nos corresponde a nosotros poder llamar a este código computacional, por ejemplo. Excel VBA.

Mira alguna guía COM / tutorial para ver lo que abstrae.

MFC es solo un conjunto de clases de contenedor GUI para la API de Win32. Mire algunos tutoriales API de Win32 para ver lo que abstrae.

Asumiendo que solo los estoy usando para programas GUI "normales" (sin COM, sin ActiveX, nada sofisticado), ¿cuál es la diferencia fundamental que veré entre ATL y MFC, para ayudarme a determinar cuál usar?

Realicé algunas búsquedas en la web, pero al final ninguna de las respuestas realmente respondió mi pregunta:

  • http://msdn.microsoft.com/en-us/library/bk8ytxz5(v=vs.80).aspx :

    • "ATL es una manera rápida y fácil de crear un componente COM en C ++ y mantener un espacio reducido. Use ATL para crear un control si no necesita todas las funciones integradas que proporciona MFC automáticamente".

      Realmente no responde mi pregunta, porque:

      • No estoy trabajando con COM.

      • ¿Esto implica que MFC no es rápido? ¿Por qué / cómo?

    • "MFC le permite crear aplicaciones completas, controles ActiveX y documentos activos. Si ya ha creado un control con MFC, es posible que desee continuar el desarrollo en MFC. Al crear un nuevo control, considere usar ATL si no necesita toda la funcionalidad incorporada de MFC ".

      Además, no responde mi pregunta porque:

      • Realmente ni siquiera sé qué es ActiveX en primer lugar.

      • Parece que Microsoft está desalentando el uso de MFC, pero no puedo entender por qué.

      • ¿Cuál es exactamente la "funcionalidad incorporada" de MFC que ATL no proporciona?

    • En general, esto no responde a mi pregunta porque no explica los inconvenientes y las razones que los respaldan.

porque directa o indirectamente, todo parece vincularse a la página anterior:

Lo que he observado actualmente (en los últimos días, al intentar aprender ambos):

  • ATL se basa en plantillas, o polimorfismo en tiempo de compilación.
    • Los métodos ATL tienden a ser no virtuales, y tienden a devolver referencias.
  • MFC se basa en métodos virtuales o en el polimorfismo de tiempo de ejecución.
    • Los métodos MFC tienden a ser virtuales y tienden a devolver punteros.

Pero no parece haber ninguna diferencia arquitectónica entre ellos :

  • Ambos usan mapas de mensajes ( BEGIN_MSG_MAP frente a BEGIN_MESSAGE_MAP ... gran cosa)
  • Ambos envuelven los métodos de Win32 en clases
  • Ambos parecen tener clases similares CWnd vs. CWindow

Pero luego, si no hay una diferencia real, excepto por el aspecto de tiempo de compilación frente a tiempo de ejecución, ¿por qué existen ambos? ¿No debería uno de ellos ser suficiente?

¿Que me estoy perdiendo aqui?

Creo que la respuesta a su pregunta es en su mayoría histórica, si mira hacia atrás cómo las dos bibliotecas se originaron y evolucionaron a través del tiempo.

La respuesta corta es: si no estás haciendo algo "elegante", usa ATL. Es genial para interfaces de usuario simples con COM lanzado.

La respuesta larga: MFC se creó a principios de los años 90 para probar este nuevo lenguaje llamado C ++ y aplicarlo a Windows. Hizo que las características similares a Office estuvieran disponibles para la comunidad de desarrollo cuando el sistema operativo aún no las tenía.

[Editar adorno: no trabajé en Microsoft, así que no sé si Office se creó en MFC, pero creo que la respuesta es no. De regreso en Win 3.1, Win 95 días, el equipo de Office UI inventaría nuevos controles, los empaquetaría en bibliotecas, luego los equipos de Windows y MFC incorporarían wrappers y API a esos controles con dlls redistribuibles. Supongo que hubo un poco de colaboración y código compartido entre esos equipos. Eventualmente esos controles llegarían al sistema operativo base en paquetes de servicio o la próxima versión de Windows. Este patrón continuó con la cinta de opciones de Office que se agregó a Windows como un componente complementario mucho después de que se incluyera Office, y ahora es parte del sistema operativo Windows.

En ese momento, la biblioteca era bastante primitiva, tanto porque el lenguaje C ++ y el compilador eran nuevos, como por el desarrollo de Microsoft a medida que evolucionó Office.

Debido a esta historia, MFC:

  1. Tiene un diseño bastante torpe Comenzó como una capa de luz alrededor de la API de Windows, pero creció. Hay un montón de pequeñas ''características'' que tuvieron que ser inventadas porque el compilador y el lenguaje simplemente no los soportaban. No había plantillas, inventaron una clase de cuerdas, inventaron clases de listas, diseñaron su propia identificación de tipo de tiempo de ejecución, etc.
  2. Encapsula 20 años de evolución de Office y Windows, que incluye una gran cantidad de cosas que probablemente nunca utilizarás: interfaces de documentos únicos y múltiples, DDE, COM, COM +, DCOM, vinculación e incrustación de documentos (para que puedas incrustar un documento de Word en su aplicación si así lo desea), controles ActiveX (evolución de incrustación de objetos para la web), Almacenamiento de documentos estructurados, Serialización y control de versiones, Automatización (desde los primeros años de VBA) y, por supuesto, MVC. Las últimas versiones tienen soporte para el acoplamiento de ventana de estilo de Visual Studio y la cinta de Office. Básicamente, todas las tecnologías de Redmond en 20 años se encuentran en algún lugar. ¡Es ENORME!
  3. Tiene un montón de pequeños problemas, errores, soluciones, suposiciones, soporte para cosas que todavía existen y que nunca usarás, y que causan problemas. Debes estar íntimamente familiarizado con la implementación de muchas clases y cómo interactúan para usarlo en un proyecto de tamaño decente. Profundizar en el código fuente de MFC durante la depuración es común. Es posible encontrar una nota técnica de 15 años sobre algún puntero que sea nulo y cause un colapso. Las suposiciones sobre la inicialización de elementos de incrustación de documentos antiguos pueden afectar su aplicación de maneras extrañas. No hay tal cosa como la abstracción en MFC, necesitas trabajar con sus peculiaridades e internos a diario, no oculta nada. Y no me hagas comenzar con el asistente de clase.

ATL se inventó a medida que evolucionó el lenguaje C ++ y llegaron las plantillas. ATL fue un ejemplo de cómo usar plantillas para evitar los problemas de tiempo de ejecución de la biblioteca MFC:

  1. Mapas de mensajes: dado que están basados ​​en plantillas, los tipos se comprueban, y si se arruina la función enlazada, no se genera. En los mapas de mensajes MFC están basados ​​en macros, y enlazados en tiempo de ejecución. Esto puede causar errores extraños, mensaje enrutado a la ventana incorrecta, un bloqueo si tiene funciones o macros definidas incorrectamente, o simplemente no funciona porque algo no está conectado correctamente. Mucho más difícil de depurar, y más fácil de romper sin darse cuenta.
  2. COM / Automatización: similar a los mapas de mensajes, COM originalmente se unió en tiempo de ejecución usando Macros, requiriendo muchos errores en la entrega y causando problemas extraños. ATL lo hizo basado en plantillas, tiempo de compilación y mucho más fácil de manejar.

[Editar Embellecimiento: En el momento en que se creó ATL, la hoja de ruta técnica de Microsoft se centró principalmente en ''Gestión de documentos''. Apple los estaba matando en el negocio de autoedición. Office ''Vinculación e incrustación de documentos'' fue un componente principal para mejorar las características ''Administración de documentos'' de Office para competir en este espacio. COM era una tecnología central inventada para la integración de aplicaciones, y las API de Incrustación de Documentos se basaban en COM. MFC fue difícil de usar para este caso de uso. ATL fue una buena solución para hacer que esta tecnología en particular sea más fácil para terceros para implementar COM y utilizar funciones de incrustación de documentos.]

Estas pequeñas mejoras hacen que ATL sea mucho más fácil de manejar en una aplicación simple que no necesita todas las características de oficina de MFC. Algo con una interfaz de usuario simple y algo de automatización de Office. Es pequeño, rápido, es tiempo de compilación y le ahorra mucho tiempo y dolor de cabeza. MFC tiene una enorme biblioteca de clases que puede ser torpe y difícil de trabajar.

Desafortunadamente, ATL se estancó. Tenía envoltorios para la API de Windows y soporte COM, y luego nunca fue más allá de eso. Cuando la Web despegó, todo esto fue olvidado como una noticia vieja.

[Editar adorno: Microsoft se dio cuenta de que esta ''cosa de Internet'' iba a ser grande. Su hoja de ruta técnica cambió drásticamente para centrarse en Internet Explorer, Windows Server, IIS, ASP, SQL Server, COM / DCOM en Servidor de transacciones distribuidas. Entonces, el enlace e incrustación de documentos ya no era una prioridad.]

La gran huella de MFC hizo que les sea imposible realizar el volcado, por lo que aún evoluciona lentamente. Las plantillas se han incorporado de nuevo a la biblioteca, así como otras mejoras de lenguaje y API. (No había oído hablar de WTL hasta que vi esta pregunta :)

En definitiva, cuál usar es simplemente una cuestión de preferencia. La mayoría de las características que necesita están en la API del sistema operativo base, a la que puede llamar directamente desde cualquiera de las bibliotecas, si no hay un contenedor adecuado en la biblioteca.

Solo mis 2 centavos basados ​​en el uso de MFC por muchos años, y los uso ahora todos los días. Incursioné en ATL cuando se lanzó por primera vez en algunos proyectos durante un par de años. Era un soplo de aire fresco en aquellos días, pero nunca realmente se fue a ninguna parte. Y luego apareció la web y lo olvidé por completo.

Editar: Esta respuesta tiene una longevidad sorprendente. Dado que sigue apareciendo en mi página de desbordamiento de pila, pensé que agregaría un poco de adorno a la respuesta original que creía que faltaba.

Muchas personas me han dicho que han usado ambos que su experiencia de programación fue menos dolorosa con ATL que con MFC. Su ejecutable compilado también será mucho más pequeño con ATL.

Te recomiendo que eches un vistazo a WTL , ya que se basa en ATL.

¿Qué es esa "funcionalidad extra" que siguen mencionando? ¿Lo necesito?

Si define sus requisitos, podría ser más fácil responder si puede evitar el uso de MFC. Desafortunadamente, "nada lujoso" no es lo suficientemente exclusivo. Ser incluyente en cuanto a las funciones que pretendes utilizar podría ser más útil (qué controles, qué marcos / tecnologías / bibliotecas existentes quieres usar, etc.).

Pero aquí hay un artículo que describe algunas características en MFC que no son compatibles directamente con WTL / ATL.

MFC también ha evolucionado hasta el punto de que admite una gran cantidad de características deseables, como MAPI, compatibilidad con los demás requisitos del logotipo de Windows, sockets, documentos (si desea y / o usa ese patrón) y archivos de documentos compuestos. WTL tiene su parte de características geniales, pero MFC es el campeón de la función clara. Ambos entornos admiten arquitecturas de ventanas principales enmarcadas (ventana de marco con ventana de vista separada), aplicaciones SDI y MDI, ventanas divididas, aplicaciones basadas en diálogo y varias clases basadas en COM para soporte COM.