Quelle est la différence fondamentale entre MFC et ATL?

En supposant que je ne les utilise que pour des programmes GUI "normaux" (pas de COM, pas d'ActiveX, rien d'extraordinaire), quelle est la différence fondamentale que je verrai entre ATL et MFC, pour m'aider à déterminer lequel utiliser?

J'ai fait quelques recherches sur le Web, mais finalement aucune des réponses n'a vraiment répondu à ma question:

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

  • «ATL est un moyen rapide et facile à la fois de créer un composant COM en C ++ et de conserver un faible encombrement. Utilisez ATL pour créer un contrôle si vous n'avez pas besoin de toutes les fonctionnalités intégrées fournies automatiquement par MFC.»

    Ne répond pas vraiment à ma question, car:

    • Je ne travaille pas avec COM.

    • Cela signifie-t-il que MFC n'est pas rapide? Pourquoi comment?

  • «MFC vous permet de créer des applications complètes, des contrôles ActiveX et des documents actifs. Si vous avez déjà créé un contrôle avec MFC, vous souhaiterez peut-être poursuivre le développement dans MFC. Lors de la création d'un nouveau contrôle, envisagez d'utiliser ATL si vous n'en avez pas besoin toutes les fonctionnalités intégrées de MFC. »

    Ne répond pas non plus à ma question, car:

    • Je ne sais vraiment pas même ce que ActiveX est en premier lieu.

    • Il semble que Microsoft décourage l'utilisation de MFC, mais je ne comprends pas pourquoi.

    • Quelle est exactement la «fonctionnalité intégrée» de MFC qu'ATL ne fournit pas?

  • En général, cela ne répond pas à ma question car cela n'explique pas les inconvénients et les raisons qui les sous-tendent.

car directement ou indirectement, tout semble renvoyer à la page précédente:

• Comment décider d'utiliser ATL, MFC, Win32 ou CLR pour un nouveau projet C ++?

  • "ATL et MFC sont un peu plus difficiles à choisir. [[Sans blague!]] Je vous renvoie à la page MSDN pour choisir afin de décider entre eux."

    De toute évidence , cela ne répond pas à ma question. :)

• http://www.codeguru.com/forum/archive/index.php/t-64778.html

• etc.

Ce que j'ai actuellement observé (au cours des deux derniers jours, en essayant d'apprendre les deux):

• ATL est basé sur des modèles ou sur un polymorphisme à la compilation.
  • Les méthodes ATL ont tendance à être non virtuelles et à renvoyer des références.
• MFC est basé sur des méthodes virtuelles ou un polymorphisme d'exécution.
  • Les méthodes MFC ont tendance à être virtuelles et à renvoyer des pointeurs.

Mais il ne semble pas y avoir de différence architecturale entre eux :

• Les deux utilisent des mappages de messages ( BEGIN_MSG_MAPvs BEGIN_MESSAGE_MAP... gros problème)
• Les deux enveloppent les méthodes Win32 dans des classes
• Les deux semblent avoir des classes similaires CWndvs.CWindow

Mais alors, s'il n'y a pas de vraie différence, sauf pour l'aspect de la compilation par rapport à celui de l'exécution, alors pourquoi les deux existent-ils? L'un d'eux ne devrait-il pas suffire?

Qu'est-ce que j'oublie ici?

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:

1. 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.
2. 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!
3. 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:

1. 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.
2. 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.

Beaucoup de gens qui ont utilisé les deux m'ont dit que leur expérience de programmation était moins douloureuse avec ATL qu'avec MFC. Votre exécutable compilé sera également beaucoup plus petit avec ATL.

Je vous recommande de jeter un œil à WTL , car il s'appuie sur ATL.

Quelle est cette «fonctionnalité supplémentaire» qu'ils continuent de mentionner? En ai-je besoin?

Si vous définissez vos exigences, il peut être plus facile de répondre si vous pouvez éviter d'utiliser MFC. Malheureusement, "rien d'extraordinaire" n'est pas assez exclusif. Être inclusif quant aux fonctionnalités que vous avez l'intention d'utiliser peut être plus utile (quels contrôles, quels frameworks / technologies / bibliothèques existantes vous souhaitez utiliser, etc.).

Mais voici un article qui décrit certaines fonctionnalités de MFC qui ne sont pas directement prises en charge par WTL / ATL.

MFC a également évolué au point qu'il prend en charge un grand nombre de fonctionnalités souhaitables, telles que MAPI, la prise en charge des autres exigences du logo Windows, les sockets, les documents (si vous aimez et / ou utilisez ce modèle) et les fichiers de documents composés. WTL a sa part de fonctionnalités intéressantes, mais MFC est clairement le champion des fonctionnalités. Les deux environnements prennent en charge les architectures de fenêtres principales encadrées (fenêtre frame avec fenêtre d'affichage séparée), les applications SDI et MDI, les fenêtres fractionnées, les applications basées sur des boîtes de dialogue et diverses classes COM pour la prise en charge COM.

ATL est un ensemble de classes destiné à simplifier l'implémentation des objets COM.

Vous pouvez l'utiliser sans MFC. Dans mon travail, nous utilisons ATL pour exposer les interfaces COM au code de calcul. Il n'y a pas d'interface graphique impliquée, c'est à nous de pouvoir appeler ce code de calcul par exemple. Excel VBA.

Regardez un guide / tutoriel COM pour voir ce qu'il résume.

MFC est simplement un ensemble de classes wrapper GUI pour l'API Win32. Regardez un didacticiel d'API Win32 pour voir ce qu'il résume.