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

Question

tl;dr:

En supposant que je suis seulement à l'aide de leur "normal" du programme avec une interface graphique (pas de COM, pas de ActiveX, rien de compliqué), quelle est la différence fondamentale que je vais voir entre ATL, MFC, pour m'aider à comprendre lequel utiliser?

---

J'ai fait quelques recherches sur le web, mais en fin de compte aucune des réponses vraiment répondu à ma question:

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

  • "ATL est un moyen rapide et facile de créer un composant COM en C++ et de maintenir un faible encombrement. Utiliser ATL pour créer un contrôle si vous n'avez pas besoin de toutes les fonctionnalités intégrées MFC fournit automatiquement."

    N'a pas vraiment répondu à ma question, parce que:

    • Je ne travaille pas avec COM.

    • Est ce que cela implique MFC n'est pas rapide? Pourquoi/comment?

  • "MFC vous permet de créer des applications complètes, les contrôles ActiveX et les documents actifs. Si vous avez déjà créé un contrôle avec les MFC, vous voudrez peut-être continuer le développement dans le MFC. Lors de la création d'un nouveau contrôle, pensez à utiliser ATL si vous n'avez pas besoin de tous les MFC est une fonctionnalité intégrée."

    Aussi ne répond pas à ma question, parce que:

    • Je n'ai pas vraiment savoir quoi ActiveX est en premier lieu.

    • Il semble que Microsoft est en décourageant l'utilisation des MFC, mais je ne peux pas comprendre pourquoi.

    • Qu'est-ce exactement est MFC "built-in fonctionnalité de" ATL ne fournit pas?

  • En général, cela ne veut pas répondre à ma question, car elle n'explique pas les inconvénients et les raisons derrière eux.

parce que, directement ou indirectement, tout semble aller pour le lien de retour à la page précédente:

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

  • "ATL & MFC sont un peu plus difficile de décider entre les deux. [[Sans blague!]] Je vous renvoie à MSDN de la page pour choisir pour choisir l'un d'entre eux."

    Évidemment, cela ne veut pas répondre à ma question. :)

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

• etc.

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

• ATL est basée sur des modèles, ou au moment de la compilation du polymorphisme.
  • ATL méthodes ont tendance à être non-virtuel, et ont tendance à retourner des références.
• MFC est basée sur des méthodes virtuelles, ou polymorphisme de l'exécution.
  • MFC méthodes ont tendance à être virtuel, et ont tendance à renvoyer les pointeurs.

Mais il ne semble pas être n'importe quel différence entre eux:

• Les deux des messages, des cartes (BEGIN_MSG_MAP vs BEGIN_MESSAGE_MAP... la belle affaire)
• Les deux envelopper Win32 méthodes dans les classes
• Les deux semblent avoir des catégories similaires CWnd vs CWindow

Mais alors, si il n'y a pas vraiment de différence, sauf pour la compilation vs run-temps, alors pourquoi faire les deux? Ne devrait pas être suffisant?

Ce qui me manque ici?

Answer 1

Je pense que la réponse à votre question est la plupart du temps historique, si vous regardez en arrière à la façon dont les deux bibliothèques est née et a évolué à travers le temps.

La réponse est courte, si tu ne fais rien de "fantaisie", l'utilisation d'ATL. C'est génial pour de simples interfaces utilisateur avec COM jeté dans.

La réponse longue: MFC a été construit dans le début des années 90 à essayer ce nouveau langage C++ et de l'appliquer à Windows. Il est devenu une base pour le Bureau et d'autres produits. À cette époque, la bibliothèque a été tout à fait primitive, à la fois parce que le langage C++ et le compilateur étant nouveau, et Microsoft à la bâtir au fil du temps en tant qu'Office évolué.

À cause de cette histoire, MFC:

1. A une assez maladroit de la conception. Il a commencé comme un peu de wrapper autour de l'API Windows, mais il a grandi. Il y a un tas de peu les 'fonctions' a dû être inventé, car le compilateur et la langue n'a tout simplement pas les soutenir. Il n'y avait pas de modèles, ils ont inventé une chaîne de classe, ils ont inventé la liste des classes, ils ont conçu leurs propres run time type identification, etc.
2. Encapsule les 20 ans de l'Office et Windows évolution, qui comprend toute une charge de merde de trucs que vous n'aurez probablement jamais utiliser: Simple et Document de Plusieurs interfaces, DDE, COM, COM+, DCOM, Document de Liaison et Incorporation (de sorte que vous pouvez incorporer un document word dans votre application si vous voulais), les contrôles ActiveX (évolution de l'incorporation de l'objet pour le web!), Structuré de Stockage de Document, la Sérialisation et la gestion des versions, de l'Automatisation (à partir de début VBA ans), et bien sûr MVC. Les dernières versions ont prise en charge de Visual Studio style de la fenêtre d'accueil, et le ruban Office. Fondamentalement, toutes les technologies de Redmond, dans 20 ans, est là quelque part. C'est juste ÉNORME!
3. A une tonne de petits problèmes, des bugs, des contournements, des hypothèses, de soutien pour les choses qui sont toujours là, que vous n'utiliserez jamais, et qu'ils causent des problèmes. Vous devez être intimement familier avec la mise en œuvre de nombreuses classes et comment ils interagissent pour l'utiliser sur une taille décente du projet. Fouiller dans le code source MFC pendant le débogage est commun. Trouver un, âgé de 15 ans note technique sur certains pointeur null causant un crash se produit toujours. Hypothèses sur l'initialisation de l'ancien document d'incorporation des choses peut nuire à votre demande en moyens détournés. Il n'y a pas une telle chose comme une abstraction dans MFC, vous devez travailler avec elle bizarreries et les internes de tous les jours, il n'a pas de cacher quoi que ce soit. Et ne me lancez pas sur l'assistant de classe.

ATL a été inventé que le langage C++ a évolué, et les modèles sont arrivés. ATL est une vitrine de l'utilisation de modèles pour éviter les problèmes d'exécution de la bibliothèque MFC:

1. Message des cartes: Puisqu'elles sont basées sur un modèle, les types sont vérifiées, et si tu vis jusqu'à la limite de la fonction, il ne fabrique pas. Dans MFC message cartes sont macro en fonction, et au moment de l'exécution lié. Cela peut causer des petits bugs, routage de message à la mauvaise fenêtre, un accident si vous avez de la fonction ou une macro définie de manière incorrecte, ou tout simplement ne pas fonctionner parce que quelque chose n'est pas accroché en haut à droite. Beaucoup plus difficile à déboguer, et plus facile à briser sans s'en apercevoir.
2. COM/Automation: Similaire à la message des cartes, COM a été à l'origine d'exécution liées à l'aide de Macros, nécessitant beaucoup d'erreur de transmission et de causer des problèmes bizarres. ATL fait à base de modèles, de la compilation, et beaucoup, beaucoup plus facile à traiter.

Ces petites améliorations ATL extrêmement plus facile à traiter sur une application simple qui n'a pas besoin de toutes les fonctionnalités du type de MFC. Quelque chose avec une INTERFACE utilisateur simple et certains bureautique jeté dans. Elle est petite, c'est rapide, c'est le temps de compilation lié économiser beaucoup de temps et des maux de tête. MFC a une énorme bibliothèque de classes qui peuvent être maladroit, et difficile à travailler.

Malheureusement, ATL a stagné. Il avait des wrappers pour les API windows et COM de soutien, et puis il n'a jamais vraiment allé au-delà. Quand le Web a décollé, tout ça était un peu oubliés comme de vieilles nouvelles. L'énorme empreinte de MFC fait qu'il est impossible pour eux de vidage, de sorte qu'il continue à évoluer lentement. (Je n'avais pas entendu parler de WTL jusqu'à ce que j'ai vu cette question. :)

Juste mes 2 cents basée sur l'utilisation des MFC depuis de nombreuses années, et je l'utilise maintenant tous les jours. J'ai barboté dans l'ATL quand il a été libéré sur quelques projets pour un couple d'années. Il a été un souffle d'air frais en ces jours, mais n'a jamais vraiment allé n'importe où. Et puis le Web est arrivé et j'ai tout oublié.

Answer 2

J'ai été dit par beaucoup de gens qui ont utilisé à la fois que leur expérience de la programmation a été moins douloureux avec ATL qu'avec les MFC. Votre exécutable compilé sera également beaucoup plus petite avec ATL.

Je vous recommande de prendre un coup d'oeil à WTL, car il s'appuie sur ATL.

Quelle est cette "fonctionnalité supplémentaire" ils gardent de mentionner? Ai-je besoin?

Si vous définissez vos besoins, il pourrait être plus facile de répondre si vous pouvez l'éviter à l'aide de MFC. Malheureusement, "rien de fantaisie" n'est pas assez exclusive. Compris les éléments que vous avez l'intention d'utiliser peut-être plus utile (qui contrôle, qui frameworks/technologies/bibliothèques existantes que vous souhaitez utiliser, etc).

Mais voici un article qui décrit certaines caractéristiques MFC qui ne sont pas directement pris en charge par WTL/ATL.

MFC a également évolué au point qu'il prend en charge un grand nombre de caractéristiques souhaitables, tels que les MAPI, le soutien pour les autres Windows logo exigences, des sockets, des documents (si vous le souhaitez et/ou de l'utilisation de ce modèle), et des fichiers de document composé. WTL a son lot de fonctionnalités intéressantes, mais MFC, la fonction de champ. Les deux environnements de soutien encadrée de la fenêtre principale de l'architecture de la fenêtre frame séparé avec fenêtre d'affichage), les applications SDI et MDI, de séparer les fenêtres, les applications en fonction de dialogue, et de diverses COM-classes de base pour la prise en charge COM.

Answer 3

ATL est un ensemble de classes destiné à simplifier la mise en oeuvre d'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’ya pas d’interface graphique, c’est à nous de pouvoir appeler ce code informatique à partir de, par exemple. Excel VBA.

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

MFC est juste un ensemble de classes wrapper d'interface graphique à l'API Win32. Regardez un didacticiel de l'API Win32 pour voir ce qu'il résume.