Comment puis-je décider d'utiliser ATL, MFC, Win32 ou CLR pour un nouveau projet C ++?
Je viens de commencer mon premier projet C++. J'utilise Visual Studio 2008 . Il s'agit d'une application Windows à formulaire unique qui accède à quelques bases de données et lance une transaction WebSphere MQ. Je comprends essentiellement les différences entre ATL, MFC, Win32 (je suis un peu flou sur celui-ci en fait) et CLR, mais je ne sais pas comment je dois choisir.
Y en a-t-il un ou plusieurs pour la compatibilité descendante?
Est-ce que CLR ne mauvaise idée ?
Toutes suggestions appréciées.
Edit: J'ai choisi C++ pour ce projet pour des raisons que je n'ai pas abordées dans le message, qui ne sont pas entièrement techniques. Donc, en supposant C++ est la seule/meilleure option, laquelle dois-je choisir?
Cela dépend de vos besoins.
L'utilisation du CLR vous fournira l'ensemble de bibliothèques le plus expressif (l'intégralité du framework .NET), au prix de limiter votre exécutable à exiger l'installation du framework .NET au moment de l'exécution, ainsi que de vous limiter à la plate-forme Windows ( cependant, les 4 technologies répertoriées sont uniquement des fenêtres, de sorte que la limitation de la plate-forme est probablement la moins gênante).
Cependant, CLR vous oblige à utiliser les extensions C++/CLI du langage C++, vous aurez donc, en substance, besoin d'apprendre quelques fonctionnalités de langage supplémentaires pour l'utiliser. Cela vous donne de nombreux "extras", tels que l'accès aux bibliothèques .net, la récupération de place complète, etc.
L'ATL et le MFC sont un peu plus difficiles à choisir. Je vous renvoie à la page de MSDN pour choisir afin de décider entre eux. La bonne chose à propos d'ATL/MFC est que vous n'avez pas besoin du framework .NET, seulement les runtimes VC/MFC à installer pour le déploiement.
L'utilisation directe de Win32 fournit les plus petits exécutables, avec le moins de dépendances, mais demande plus de travail à écrire. Vous avez le moins de bibliothèques d'aide, donc vous écrivez plus de code.
Win32 est le moyen brut et nu-métal de le faire. C'est fastidieux, difficile à utiliser et contient de nombreux petits détails dont vous devez vous souvenir, sinon les choses échoueront de manière relativement mystérieuse.
MFC s'appuie sur Win32 pour vous fournir une manière orientée objet de créer votre application. Ce n'est pas un remplacement pour Win32, mais plutôt une amélioration - il fait beaucoup de travail pour vous.
System.Windows.Forms (ce que je suppose que vous entendiez par CLR) est complètement différent mais présente de grandes similitudes avec MFC par rapport à sa structure de base. C'est de loin le plus facile à utiliser, mais nécessite le framework .NET, qui peut ou non être un obstacle dans votre cas.
Ma recommandation: si vous devez éviter .NET, utilisez MFC, sinon utilisez .NET (en fait, dans ce cas, j'utiliserais C # car il est beaucoup plus facile de travailler avec).
En ce qui concerne C++, j'utiliserais WTL. C'est léger et vous aurez peu (le cas échéant) de dépendances, ce qui le rendra facile à expédier et à installer. Je trouve cela très satisfaisant lorsque mon application se compose d'un seul EXE qui s'exécutera sur la plupart des versions de Windows, mais cela peut ne pas vous préoccuper.
Si vous choisissez d'aller .NET à la place, alors C # est presque certainement la voie à suivre.
Plus en WTL ici:
Je serais très curieux de savoir pourquoi vous feriez cela en C++. Sur la base de votre brève description, C # semble être un choix beaucoup plus approprié.
Juste pour développer un peu, regardez le lien que vous avez donné décrivant le C++ CLR. La réponse la mieux notée note (avec précision, à mon avis) que C++ est approprié pour "les applications de noyau, de jeux, de haute performance et de serveur" - dont aucune ne semble décrire ce que vous faites.
MFC, ATL, etc. vont être pris en charge dans le sens où, oui, vous pourrez compiler votre application sur les futures versions de Visual Studio et les exécuter sur les futures versions de Windows. Mais ils ne sont pas pris en charge dans le sens où il n'y a pas beaucoup de nouveaux développements en cours dans l'API ou dans le langage de la même manière que dans le CLR et le C #.
Il n'y a rien de mal avec CLR. Comme d'autres ici, je suggère C # mais comme vous avez des raisons de rester avec C++, l'utilisation du framework .NET est plusieurs milliers de fois plus facile que de jouer avec ATL/MFC si vous ne les connaissez pas déjà (IMO).
Il peut être utile de mentionner que si vous utilisez C++/CLR, vous n'utilisez pas vraiment C++ du tout. C++/CLR se compile en CIL comme C #. Je ne l'ai jamais utilisé moi-même, mais je pense que son objectif est de vous permettre de compiler du code hérité et de le rendre facilement disponible pour le nouveau code .NET plutôt que de permettre au nouveau code de fonctionner avec les anciens exécutables C++. Il existe d'autres méthodes d'appel de code natif à partir de .NET que vous devriez peut-être explorer.