web-dev-qa-db-fra.com

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

En supposant que je seulement les utilise pour des programmes GUI "normaux" (pas de COM, pas d'ActiveX, rien d'extraordinaire), quelle est la différence fondamentale Je vais voir entre ATL et MFC, pour m'aider à trouver 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 une petite empreinte. Utilisez ATL pour créer un contrôle si vous n'avez pas besoin de toutes les fonctionnalités intégrées que MFC fournit automatiquement. "

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

      • Je ne travaille pas avec COM.

      • Cela implique-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'ont pas besoin de toutes les fonctionnalités intégrées de MFC. "

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

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

      • Il semble que Microsoft décourage l'utilisation du MFC, mais je n'arrive pas à comprendre pourquoi.

      • Qu'est-ce exactement est "fonctionnalité intégrée" du 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 derrière eux.

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

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 le 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 sur le polymorphisme d'exécution.
    • Les méthodes MFC ont tendance à être virtuelles et à renvoyer des pointeurs.

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

  • Les deux utilisent des mappages de messages (BEGIN_MSG_MAP contre. BEGIN_MESSAGE_MAP... grosse affaire)
  • Les deux enveloppent les méthodes Win32 dans des classes
  • Les deux semblent avoir des classes similaires CWnd vs CWindow

Mais alors, s'il n'y a pas de réelle différence à l'exception de l'aspect de la compilation par rapport à 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?

c++visual-c++mfcatl
100
Mehrdad

Je pense que la réponse à votre question est principalement historique, si vous regardez en arrière comment les deux bibliothèques sont nées et ont évolué au fil du temps.

La réponse courte est, si vous ne faites rien de "fantaisiste", utilisez ATL. Il est idéal pour les interfaces utilisateur simples avec COM intégré.

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. Il a rendu Office comme les fonctionnalités disponibles pour la communauté de développement lorsque le système d'exploitation ne les avait pas encore.

[Modifier l'embellissement: je ne travaillais pas chez Microsoft, donc je ne sais pas si Office a jamais été construit sur MFC, mais je pense que la réponse est non. De retour dans Win 3.1, Win 95 jours, l'équipe Office UI inventerait de nouveaux contrôles, les regrouperait dans des bibliothèques, puis les équipes Windows et MFC incorporeraient des wrappers et des API à ces contrôles avec des DLL redistribuables. Je suppose qu'il y avait un peu de collaboration et de partage de code entre ces équipes. Finalement, ces contrôles entreraient dans 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 fait désormais partie du système d'exploitation Windows.]

À cette époque, la bibliothèque était assez primitive, à la fois en raison de la nouveauté du langage C++ et du compilateur, et de la création de Microsoft au fil du temps à mesure qu'Office évoluait.

En raison de cette histoire, MFC:

  1. A un design assez maladroit. Il a commencé comme un wrapper léger autour de l'API Windows, mais a grandi. Il y a un tas de petites "fonctionnalités" qui ont dû être inventées parce que le compilateur et le langage ne les prenaient tout simplement pas en charge. 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, ce qui inclut une charge de merde entière de choses que vous n'utiliserez probablement jamais: interfaces de document unique et multiple, DDE, COM, COM +, DCOM, liaison de lien et incorporation (afin que vous puissiez incorporer un document Word dans votre application si vous le souhaitez), les contrôles ActiveX (évolution de l'intégration d'objets pour le web!), le stockage structuré de documents, la sérialisation et le contrôle de version, l'automatisation (depuis les premières années VBA) et bien sûr MVC. Les dernières versions prennent en charge l'ancrage des fenêtres de style Visual Studio et le ruban Office. Fondamentalement, toutes les technologies de Redmond en 20 ans se trouvent quelque part. C'est juste ÉNORME!
  3. A une tonne de petits accrochages, bogues, solutions de contournement, hypothèses, support pour des choses qui sont toujours là que vous n'utiliserez jamais, et ils 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. Plonger dans le code source MFC pendant le débogage est courant. Il est toujours possible de trouver une note technique de 15 ans sur un pointeur nul qui provoque un crash. Les hypothèses sur l'initialisation de documents d'ancrage de documents anciens peuvent affecter votre application de manière étrange. L'abstraction n'existe pas 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é à mesure que le langage C++ évoluait et que des modèles arrivaient. ATL était une vitrine sur la façon d'utiliser des modèles pour éviter les problèmes d'exécution de la bibliothèque MFC:

  1. Mappages de messages: Puisqu'ils sont basés 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 à l'exécution. Cela peut provoquer 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 fonctionne pas parce que quelque chose n'est pas correctement connecté. Beaucoup plus difficile à déboguer et plus facile à casser sans s'en rendre compte.
  2. COM/Automation: similaire aux mappages de messages, COM était à l'origine lié à l'exécution à l'aide de macros, nécessitant de nombreuses erreurs et provoquant des problèmes étranges. ATL l'a rendu basé sur un modèle, compilé en fonction du temps et 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. La "liaison et l'incorporation de documents" d'Office était un élément principal pour améliorer les fonctionnalités de "gestion de documents" d'Office afin de concurrencer dans cet espace. COM était un noyau technologie inventée pour l'intégration des applications, et les API d'intégration de documents étaient basées sur COM. MFC était difficile à utiliser dans ce cas d'utilisation. ATL était une bonne solution pour rendre cette technologie particulière plus facile pour les tiers d'implémenter COM et d'utiliser les fonctionnalités d'intégration de documents.]

Ces petites améliorations facilitent énormément la gestion d'ATL 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. C'est petit, c'est rapide, c'est du temps de compilation qui vous fait gagner beaucoup de temps et de maux de tête. MFC possède une énorme bibliothèque de classes qui peuvent être maladroites et difficiles à travailler.

Malheureusement, ATL a stagné. Il avait des wrappers pour le support Windows API et COM, puis il n'a jamais vraiment dépassé cela. Lorsque le Web a décollé, tout cela a été en quelque sorte oublié comme une vieille nouvelle.

[Modifier l'embellissement: Microsoft a réalisé que cette "chose Internet" allait être grande. 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. La liaison et l'incorporation de documents n'étaient donc plus une priorité élevée.]

L'énorme empreinte du MFC a rendu impossible le vidage, il évolue donc lentement. Les modèles ont été réintégrés dans la bibliothèque, ainsi que d'autres améliorations du langage et de l'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 d'encapsuleur approprié dans la bibliothèque.

Juste mes 2 cents basés sur l'utilisation du 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 à cette é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 d'apparaître dans ma page de débordement de pile, j'ai pensé ajouter un embellissement à la réponse originale que je pensais faire défaut.

162
Jay

Beaucoup de gens 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 jetez un oeil à 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 besoins, il pourrait être plus facile de répondre si vous pouvez éviter d'utiliser MFC. Malheureusement, "rien d'extraordinaire" n'est pas assez exclusif. Il peut être plus utile d'inclure les fonctionnalités que vous avez l'intention d'utiliser (quels contrôles, quels cadres/technologies/bibliothèques existantes vous souhaitez utiliser, etc.).

Mais voici n 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 de prendre en charge de nombreuses fonctionnalités souhaitables, telles que MAPI, la prise en charge des autres exigences de 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 le champion des fonctionnalités claires. Les deux environnements prennent en charge les architectures de fenêtre principale encadrées (fenêtre de cadre avec fenêtre de vue 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 basées sur COM pour la prise en charge COM.

18
Merlyn Morgan-Graham

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 aucune interface graphique impliquée, c'est pour nous d'être en mesure d'appeler ce code de calcul par exemple. Excel VBA.

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

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

9
Alexandre C.