2009-05-04 19 views
62

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.¿Cómo decido si usar ATL, MFC, Win32 o CLR para un nuevo proyecto de C++?

¿Hay uno o más de estos para compatibilidad retroactiva?

¿Es CLR a bad idea?

Cualquier sugerencia apreciada.

Editar: He elegido C++ para este proyecto por razones que no incluí en la publicación, que no son del todo técnicas. Entonces, asumiendo C++ es la única/mejor opción, ¿cuál debería elegir?

Respuesta

66

Depende de sus necesidades.

El uso del CLR le proporcionará el conjunto de librerías más expresivo (todo el framework .NET), al costo de restringir su ejecutable para requerir que .NET framework se instale en tiempo de ejecución, así como también limitarlo a la plataforma de Windows (sin embargo, las 4 tecnologías enumeradas son solo de Windows, por lo que la limitación de la plataforma es probablemente la menos problemática).

Sin embargo, CLR requiere que utilice las extensiones de C++/CLI para el lenguaje C++, por lo que deberá, en esencia, aprender algunas características adicionales del idioma para poder utilizarlo. Si lo hace, obtendrá muchos "extras", como acceso a las bibliotecas .net, recolección de basura completa, etc.

ATL & MFC son un poco más difíciles de decidir. Me gustaría referirlo a MSDN's page for choosing 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 de escritura. Tiene la menor cantidad de bibliotecas de ayuda, por lo que está escribiendo más código.

7

Me gustaría saber por qué lo haría en C++ en absoluto. Según su breve descripción, C# suena como una opción mucho más apropiada.

Solo por elaborar un poco, mire el enlace que dio describiendo el 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 futuras versiones de Visual Studio y ejecutarlas en futuras versiones 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#.

+0

Buena pregunta. Es parte de un proyecto más grande que incluye algunas otras piezas que tienen que estar en C++ por razones relacionadas con legado y proveedores. Esta parte no * tiene * que estar en C++ pero como hay otras partes que sí lo tienen, y dado que esta parte es relativamente pequeña, estaba planeando hacerlo todo en el mismo idioma. –

+0

C++/CLI (/ clr) puede estar muy cerca de C#, si le gusta trabajar en C#, pero quiere/necesita usar C++. La principal diferencia son algunas cosas menores de sintaxis, y tratar de evitar el uso de C++ estándar en lugar de las llamadas al CLI. Realmente no hay razón para evitarlo. –

+0

Y eso no es necesariamente un mal proceso de pensamiento. Sin embargo, todavía creo que lo mejor es ir C# y P/Invoke en sus bibliotecas existentes. Si ya era * un * gurú de MFC, y esto era solo una pequeña adición a su proyecto, entonces sí, probablemente tendría sentido continuar en C++. Aunque incluso en ese caso podría ser una buena oportunidad para crear un "tiempo de práctica" con .NET framework – Clyde

18

Win32 es la forma básica 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 entiende por 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, utilice MFC, de lo contrario utilice .NET (de hecho, en ese caso utilizaría C# porque es mucho más fácil trabajar con él).

+1

¿Este comentario todavía está actualizado? –

+0

Para Visual Studio 2008, probablemente, aunque ya tenga una década. En estos días, para Windows, es mucho mejor usar WPF. – arke

13

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 .NET en su lugar, entonces C# es casi seguro que es el camino a seguir.

Más en WTL aquí:

http://www.codeproject.com/KB/wtl/wtl4mfc1.aspx

+1

¿Seguiría usando WTL? No hay compromisos para 2016, todavía. Fuente: [SVN] (https://sourceforge.net/p/wtl/code/631/log/?path=) –

4

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á usando C++/CLR, entonces realmente no está 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.

+0

Si tengo que usar la biblioteca .NET, prefiero escribir en C# – Sakura

Cuestiones relacionadas