¿Cómo decido si usar ATL, MFC, Win32 o CLR para un nuevo proyecto de C++?
winapi (5)
Depende de tus necesidades.
El uso de CLR le proporcionará el conjunto de librerías más expresivo (todo el framework .NET), a costa de restringir su ejecutable para requerir que el .NET Framework se instale en tiempo de ejecución, así como también lo limitará a la plataforma de Windows ( sin embargo, las 4 tecnologías enumeradas son solo ventanas, por lo que la limitación de la plataforma es probablemente la menos problemática).
Sin embargo, CLR requiere que uses las extensiones de C ++ / CLI para el lenguaje C ++, por lo que, en esencia, necesitarás aprender algunas características adicionales del lenguaje para usar esto. Si lo hace, obtendrá muchos "extras", como acceso a las bibliotecas .net, recolección completa de basura, etc.
ATL y MFC son un poco más difíciles de decidir. Me referiría a la página de MSDN para elegir para decidir entre ellos. Lo bueno de ATL / MFC es que no necesita .NET Framework, solo los tiempos de ejecución de VC / MFC que se instalarán para la implementación.
El uso de Win32 proporciona directamente los archivos ejecutables más pequeños, con la menor cantidad de dependencias, pero es más trabajo para escribir. Tiene la menor cantidad de bibliotecas de ayuda, por lo que está escribiendo más código.
Estoy comenzando mi primer proyecto de C ++. Estoy usando Visual Studio 2008 . Es una aplicación de Windows de una sola forma que accede a un par de bases de datos e inicia una transacción de WebSphere MQ. Básicamente, entiendo las diferencias entre ATL, MFC, Win32 (soy un poco confuso en eso en realidad) y CLR, pero no sé cómo elegir.
¿Hay uno o más de estos para compatibilidad retroactiva?
¿Es CLR una mala idea ?
Cualquier sugerencia apreciada.
Editar: Elegí C ++ para este proyecto por razones que no incluí en la publicación, que no son del todo técnicas. Entonces, asumiendo que C ++ es la única / mejor opción, ¿cuál debería elegir?
En cuanto a C ++, usaría WTL. Es lightweght y tendrá pocas (si las hay) dependencias, lo que facilita su envío e instalación. Me parece muy satisfactorio cuando mi aplicación consiste en un único EXE que se ejecutará en la mayoría de las versiones de Windows, pero puede que esto no le preocupe.
Si elige ir a .NET en su lugar, entonces C # es casi seguro que es el camino a seguir.
Más en WTL aquí:
No hay nada malo con CLR. Al igual que otros aquí, sugeriría C # pero como tiene razones para seguir con C ++, usar el framework .NET es miles de veces más fácil que jugar con ATL / MFC si no está familiarizado con ellos (IMO).
Vale la pena mencionar que si estás usando C ++ / CLR, entonces realmente no estás usando C ++. C ++ / CLR compila a CIL al igual que C #. Nunca lo he usado, pero creo que su propósito es permitirle compilar el código heredado y hacerlo fácilmente disponible para el nuevo código .NET en lugar de permitir que el nuevo código funcione con viejos ejecutables de C ++. Existen otros métodos para llamar al código nativo de .NET que, quizás, deba explorar.
Sería muy curioso sobre por qué harías esto en C ++ en absoluto. Según su breve descripción, C # suena como una opción mucho más apropiada.
Solo para elaborar un poco, mira el enlace que describiste describiendo C ++ CLR. Las notas de respuesta mejor calificadas (con precisión, en mi opinión) de que C ++ es apropiado para "kernel, juegos, alto rendimiento y aplicaciones de servidor", ninguna de las cuales parece describir lo que estás haciendo.
MFC, ATL, etc. serán compatibles en el sentido de que, sí, podrá compilar su aplicación en versiones futuras de Visual Studio y ejecutarlas en versiones futuras de Windows. Pero no son compatibles en el sentido de que no hay muchos desarrollos nuevos en la API o el lenguaje de la misma manera que en CLR y C #.
Win32 es la manera básica y simple de hacerlo. Es tedioso, difícil de usar y tiene muchos detalles pequeños que debes recordar, de lo contrario las cosas fracasarán de maneras relativamente misteriosas.
MFC se basa en Win32 para proporcionarle una forma orientada a objetos de creación de su aplicación. No es un reemplazo para Win32, sino más bien una mejora: hace mucho del trabajo duro por ti.
System.Windows.Forms (que es lo que supongo que quiso decir con CLR) es completamente diferente, pero tiene grandes similitudes con MFC desde su estructura básica. Es de lejos el más fácil de usar, pero requiere .NET Framework, que puede o no ser un obstáculo en su caso.
Mi recomendación: si necesita evitar .NET, use MFC, de lo contrario use .NET (de hecho, en ese caso utilizaría C # porque es mucho más fácil trabajar con él).