Je pense que la réponse à votre question est surtout historique, si vous regardez en arrière comment les deux bibliothèques ont vu le jour et ont évolué au fil du temps.
La réponse courte est, si vous ne faites rien de «sophistiqué», utilisez ATL. C'est idéal pour les interfaces utilisateur simples avec COM ajouté.
La réponse longue: MFC a été construit au début des années 90 pour essayer ce nouveau langage appelé C ++ et l'appliquer à Windows. Cela a rendu les fonctionnalités d'Office disponibles à la communauté de développement lorsque le système d'exploitation ne les avait pas encore.
[Modifier l'embellissement: je n'ai pas travaillé chez Microsoft, donc je ne sais pas si Office a déjà été construit sur MFC, mais je pense que la réponse est non. De retour dans Win 3.1, Win 95 jours, l'équipe de l'interface utilisateur d'Office inventait de nouveaux contrôles, les regroupait dans des bibliothèques, puis les équipes Windows et MFC incorporaient des wrappers et une API à ces contrôles avec des dll redistribuables. Je suppose qu'il y a eu un peu de collaboration et de partage de code entre ces équipes. Finalement, ces contrôles deviendraient le système d'exploitation de base dans les Service Packs ou la prochaine version de Windows. Ce modèle s'est poursuivi avec le ruban Office qui a été ajouté à Windows en tant que composant complémentaire bien après la livraison d'Office et qui fait désormais partie du système d'exploitation Windows.]
À cette époque, la bibliothèque était assez primitive, à la fois en raison du fait que le langage C ++ et le compilateur étaient nouveaux, et que Microsoft l'a construit au fil du temps à mesure qu'Office évoluait.
En raison de cet historique, MFC:
- A un design assez maladroit. Cela a commencé comme un wrapper léger autour de l'API Windows, mais s'est développé. Il y a un tas de petites «fonctionnalités» qui ont dû être inventées parce que le compilateur et le langage ne les supportaient tout simplement pas. Il n'y avait pas de modèles, ils ont inventé une classe de chaînes, ils ont inventé des classes de liste, ils ont conçu leur propre identification de type d'exécution, etc.
- Encapsule 20 ans d'évolution d'Office et de Windows, qui comprend toute une merde de choses que vous n'utiliserez probablement jamais: interfaces de document unique et multiple, DDE, COM, COM +, DCOM, liaison et intégration de documents (vous pouvez donc incorporer un document Word dans votre application si vous le souhaitez), des contrôles ActiveX (évolution de l'intégration d'objets pour le Web!), du stockage structuré de documents, de la sérialisation et du contrôle des versions, de l'automatisation (depuis les premières années de VBA) et bien sûr de MVC. Les dernières versions prennent en charge l'ancrage des fenêtres de style Visual Studio et le ruban Office. En gros, chaque technologie de Redmond en 20 ans est là quelque part. C'est juste ÉNORME!
- A une tonne de petits pièges, bugs, solutions de contournement, hypothèses, support pour des choses qui sont toujours là et que vous n'utiliserez jamais, et qui causent des problèmes. Vous devez être intimement familier avec l'implémentation de nombreuses classes et comment elles interagissent pour l'utiliser sur un projet de taille décente. Explorer le code source MFC pendant le débogage est courant. Trouver une note technique de 15 ans sur un pointeur étant nul, provoquant un crash se produit toujours. Les hypothèses sur l'initialisation des éléments d'intégration de documents anciens peuvent affecter votre application de manière étrange. Il n'y a pas d'abstraction dans MFC, vous devez travailler quotidiennement avec ses bizarreries et ses internes, cela ne cache rien. Et ne me lancez pas sur l'assistant de classe.
ATL a été inventé au fur et à mesure de l'évolution du langage C ++ et des modèles sont arrivés. ATL était une vitrine de la façon d'utiliser des modèles pour éviter les problèmes d'exécution de la bibliothèque MFC:
- Cartes de messages: puisqu'elles sont basées sur des modèles, les types sont vérifiés et si vous bousillez la fonction liée, elle ne se construit pas. Dans MFC, les mappages de messages sont basés sur des macros et liés au moment de l'exécution. Cela peut causer des bogues étranges, un message acheminé vers la mauvaise fenêtre, un crash si vous avez une fonction ou une macro définie de manière incorrecte, ou tout simplement ne pas fonctionner parce que quelque chose n'est pas correctement connecté. Beaucoup plus difficile à déboguer et plus facile à casser sans s'en apercevoir.
- COM / Automation: Semblable aux mappages de messages, COM était à l'origine lié au moment de l'exécution à l'aide de macros, nécessitant beaucoup de traitement des erreurs et causant des problèmes étranges. ATL l'a rendu basé sur un modèle, lié au temps de compilation et beaucoup, beaucoup plus facile à gérer.
[Modifier l'embellissement: Au moment de la création d'ATL, la feuille de route technique de Microsoft était principalement axée sur la «gestion des documents». Apple les tuait dans le secteur de la publication assistée par ordinateur. Office «Document Linking and Embedding» était un élément principal pour améliorer les fonctionnalités de «Document Management» d'Office afin de concurrencer dans cet espace. COM était une technologie de base inventée pour l'intégration d'applications, et les API d'intégration de documents étaient basées sur COM. MFC était difficile à utiliser pour ce cas d'utilisation. ATL était une bonne solution pour rendre cette technologie particulière plus facile pour les tiers à implémenter COM et à utiliser les fonctionnalités d'incorporation de documents.]
Ces petites améliorations rendent ATL extrêmement plus facile à gérer sur une application simple qui n'a pas besoin de toutes les fonctionnalités bureautiques de MFC. Quelque chose avec une interface utilisateur simple et un peu de bureautique ajouté. C'est petit, c'est rapide, c'est un temps de compilation limité qui vous fait gagner beaucoup de temps et de maux de tête. MFC a une énorme bibliothèque de classes qui peuvent être maladroites et difficiles à utiliser.
Malheureusement, ATL a stagné. Il avait des wrappers pour l'API Windows et la prise en charge COM, et cela n'a jamais vraiment dépassé cela. Lorsque le Web a décollé, tout ce truc était en quelque sorte oublié comme de vieilles nouvelles.
[Modifier l'embellissement: Microsoft s'est rendu compte que cette «chose Internet» allait être importante. Leur feuille de route technique a radicalement changé pour se concentrer sur Internet Explorer, Windows Server, IIS, ASP, SQL Server, COM / DCOM dans Distributed Transaction Server. Ainsi, la liaison et l'incorporation de documents n'étaient plus une priorité élevée.]
L'énorme encombrement de MFC leur a rendu impossible le vidage, il évolue donc encore lentement. Des modèles ont été réintégrés dans la bibliothèque, ainsi que d'autres améliorations de langage et d'API. (Je n'avais pas entendu parler de WTL avant d'avoir vu cette question. :)
En fin de compte, lequel utiliser est simplement une question de préférence. La majorité des fonctionnalités dont vous avez besoin se trouvent dans l'API du système d'exploitation de base, que vous pouvez appeler directement à partir de l'une ou l'autre bibliothèque, s'il n'y a pas de wrapper approprié dans la bibliothèque.
Juste mes 2 cents basés sur l'utilisation de MFC pendant de nombreuses années, et je l'utilise maintenant quotidiennement. J'ai essayé ATL lors de sa première sortie sur quelques projets pendant quelques années. C'était une bouffée d'air frais à l'époque, mais jamais vraiment allé nulle part. Et puis le Web est arrivé et j'ai tout oublié.
Edit: Cette réponse a une longévité surprenante. Puisqu'il continue à apparaître dans ma page de débordement de pile, j'ai pensé ajouter un peu d'embellissement à la réponse originale qui me manquait.