Was ist der grundlegende Unterschied zwischen MFC und ATL?

Vorausgesetzt, ich bin nur Sie für die "normale" GUI-Programme (kein COM, kein ActiveX, nichts besonderes), was ist der fundamentale Unterschied, den ich zwischen ATL und MFC, mir zu helfen, herauszufinden, welche zu verwenden?

Ich habe getan, einige suchen im web, aber letztlich keine der Antworten wirklich meine Frage beantwortet:

  • http://msdn.microsoft.com/en-us/library/bk8ytxz5(v=vs. 80).aspx:
    • "ATL ist eine schnelle, einfache Möglichkeit zum erstellen einer COM-Komponente in C++ und halten eine kleine Stellfläche. Verwenden Sie zum erstellen einer ATL-Steuerelement, wenn Sie brauchen nicht alle built-in-Funktionen, die MFC automatisch zur Verfügung stellt."

      Nicht wirklich meine Frage beantworten, weil:

      • Ich arbeite nicht mit COM.
      • Bedeutet dies MFC nicht schnell? Warum/wie?
    • "MFC-ermöglicht Ihnen das erstellen von vollständigen Anwendungen, ActiveX-Steuerelemente und active-Dokumente. Wenn Sie bereits ein Steuerelement mit MFC, möchten Sie vielleicht, um die Weiterentwicklung in MFC. Beim erstellen ein neues Steuerelement, sollten Sie mithilfe von ATL-wenn Sie nicht brauchen, alle von der MFC-built-in-Funktionalität".

      Ist auch nicht meine Frage beantworten, weil:

      • Ich nicht wirklich einmal wissen, was ActiveX ist in den ersten Platz.
      • Sieht es aus, als ob Microsoft entmutigt die Verwendung von MFC, aber ich kann nicht herausfinden, warum.
      • Was genau ist MFC "built-in-Funktionen" ATL nicht?
    • Im Allgemeinen, dies beantwortet nicht meine Frage, weil es nicht erklären, die Nachteile und die Gründe hinter Ihnen.

weil direkt oder indirekt, alles scheint zu link zurück, um zur vorherigen Seite:

Was ich derzeit beobachtet (in den letzten paar Tagen, bei dem Versuch, beides zu erlernen):

  • ATL ist, die auf Vorlagen basieren, oder compile-Zeit-Polymorphismus.
    • ATL-Methoden neigen dazu, nicht-virtuellen, und neigen dazu, die Referenzen zurückgeben.
  • MFC-basiert auf virtuellen Methoden oder Laufzeit-Polymorphie.
    • MFC-Methoden neigen dazu, virtuelle und tendenziell zurück Zeigern.

Aber es scheint nicht zu jedem architektonischen Unterschied zwischen Ihnen:

  • Beide verwenden die message-maps (BEGIN_MSG_MAP vs. BEGIN_MESSAGE_MAP... big deal)
  • Beide wrap-Win32-Methoden in Klassen
  • Beide scheinen zu ähnlichen Klassen CWnd vs. CWindow

Aber dann, wenn es keinen wirklichen Unterschied, außer für den compile-time vs. run-time-Aspekt, warum dann nicht beide existieren? Sollte nicht einer von Ihnen genug sein?

Was vermisse ich hier?

InformationsquelleAutor der Frage Mehrdad | 2011-08-27

  1. 133

    Ich denke, die Antwort auf Ihre Frage ist meist historische, wenn Sie zurückblicken, wie die beiden Bibliotheken entstanden und entwickelt durch die Zeit.

    Die kurze Antwort ist, wenn Sie nicht tun, alles, was "schick" ist, verwenden Sie ATL. Es ist großartig für einfache user-Schnittstellen, die mit COM geworfen.

    Die lange Antwort:
    MFC wurde in den frühen 90er-Jahren zu versuchen, diese neue Sprache namens C++ und wenden Sie es zu Windows. Es machte Office-ähnliche Funktionen zur Verfügung, um die Entwicklung der Gemeinschaft, wenn das OS nicht haben, Sie noch nicht.

    [Bearbeiten Verschönerung: habe ich nicht bei Microsoft arbeiten, also ich weiß nicht, ob Office jemals gebaut wurde auf MFC, aber ich denke, die Antwort ist Nein. Zurück in Win 3.1, Win 95 Tagen, Office UI-team zu erfinden, neue Steuerelemente, Verpacken Sie Sie in Bibliotheken, dann die Windows-und MFC-teams einbringen würde-Wrapper und-API, um diese Steuerelemente mit redistributable-dlls. Ich würde vermuten, es war ein bisschen der Zusammenarbeit und des code-sharing zwischen diesen teams. Schließlich diejenigen, die Kontrollen wäre es in der Basis-Betriebssystem, service packs oder der nächsten Windows-version. Dieses Muster fortgesetzt mit der Office-Multifunktionsleiste, die Hinzugefügt wurde, der in Windows als add-on-Komponente gut nach Büro geliefert, und ist nun Teil des Windows Betriebssystems.]

    Damals die Bibliothek war ziemlich primitiv, sowohl wegen der Sprache C++ und compiler neu, und Microsoft baut Sie im Laufe der Zeit als Büro entwickelt.

    Wegen dieser Geschichte, MFC:

    1. Hat einen ziemlich klobigen design. Es begann als Licht-wrapper um die Windows API, aber wuchs. Es gibt ein paar kleine "features", die erfunden werden musste, da der compiler und die Sprache einfach nicht unterstützen. Es gab keine Vorlagen, Sie erfand eine string-Klasse, die Sie erfanden, Liste Klassen gestalteten Sie Ihre eigene run time type identification, etc.
    2. Kapselt 20 Jahre Office-und Windows-Entwicklung, die beinhaltet eine ganze Mist Belastung von Sachen, die Sie wahrscheinlich nie verwenden: Single und Multiple Document interfaces, DDE, COM, COM+, DCOM, Dokument Linking and Embedding (einbetten eines word-Dokuments in Ihre app, wenn Sie wollte), ActiveX-Steuerelemente (Entwicklung des Objekt-Einbettung für das web!), Strukturierte Ablage von Dokumenten, die Serialisierung und Versionierung, Automatisierung (von der frühen VBA Jahre), und natürlich mit MVC. Die neuesten Versionen haben Unterstützung für Visual Studio Stil docking-Fenster, und die Office-Multifunktionsleiste. Grundsätzlich ist jede Technologie aus Redmond in 20 Jahren ist dort irgendwo. Es ist einfach RIESIG!
    3. Hat eine Tonne der kleinen Probleme, bugs, workarounds, Annahmen, die Unterstützung für Dinge, die noch da sind, dass Sie benutzen Sie nie, und Sie verursachen Probleme. Sie müssen vertraut sein mit der Durchführung vieler Klassen und wie Sie interagieren, Sie auf eine anständige Größe-Projekt. Eintauchen in die MFC-source-code während des Debuggens ist üblich. Suche eine 15-jährige tech-Hinweis auf einige Zeiger null verursacht einen Absturz passiert immer noch. Annahmen bei der Initialisierung von alten-Dokument einbetten Sachen können Einfluss auf Ihre Anwendung in seltsame Wege. Es gibt keine solche Sache wie Abstraktion in der MFC, die Sie benötigen, um mit zu arbeiten es Macken und Interna täglich, es hat nichts zu verbergen. Und verstehen Sie mich nicht begonnen auf den Klassen-Assistenten.

    ATL erfunden wurde, als die Sprache C++ entwickelt, und Vorlagen kam. ATL war ein Schaufenster, wie Sie Vorlagen verwenden, um zu vermeiden, die Laufzeit-Probleme der MFC-Bibliothek:

    1. Message-maps: Sie sind Seit Vorlage basiert, sind die Typen überprüft, und wenn Sie es vermasseln die Funktion gebunden, es nicht zu bauen. In MFC-message-maps-makro basiert, und die Laufzeit gebunden. Dies kann die Ursache für seltsame bugs, die Nachricht an das falsche Fenster, die ein Abstürzen, wenn Sie die Funktion oder das makro nicht korrekt definiert, oder einfach nicht funktionieren, weil etwas nicht richtig angeschlossen. Viel schwieriger zu Debuggen und einfacher zu brechen, ohne Sie zu bemerken.
    2. COM/Automation: Ähnlich wie die message-maps, COM war ursprünglich Laufzeit gebunden mit Makros erfordern viel Fehlerbehandlung und verursacht seltsame Probleme. ATL machte es template basiert, der Kompilierung gebunden, und viel, viel einfacher zu handhaben.

    [Bearbeiten Verschönerung: Bei der ATL erstellt wurde, Microsoft technical road map konzentrierte sich hauptsächlich auf die 'Dokumenten-Management'. Apple war, Sie zu töten, in die desktop-publishing-Geschäft. Office-Dokument Verknüpfen und Einbetten " war eine wesentliche Komponente zur Verbesserung der 'Dokumenten-Management' - Funktionen von Microsoft Office zu konkurrieren in diesem Raum. COM war eine core-Technologie erfunden, die für die integration von Anwendungen und Dokument Einbetten API ' s basieren auf COM. MFC war schwierig, Sie zu verwenden, für diesen Anwendungsfall. ATL war eine gute Lösung, um diese Besondere Technologie einfacher für 3rd-party - implementieren von COM-und nutzen-Dokument einbetten-Funktionen.]

    Diese kleinen Verbesserungen machen ATL enorm einfacher zu handhaben, auf eine einfache Anwendung, die nicht braucht, alle office-ähnliche Funktionen des MFC. Etwas, das mit einer einfachen Benutzeroberfläche und einige Office-automation geworfen. Es ist klein, es ist schnell, es ist der Kompilierung gebunden, sparen Sie viel Zeit und Kopfschmerzen. MFC hat eine riesige Bibliothek von Klassen, klobig und schwer, mit zu arbeiten.

    Leider ATL stagnierte. Es hatte Wrapper für die windows-API und COM-support, und dann ist es nie wirklich ging darüber hinaus. Wenn die Web begann, all das Zeug war sowas von vergessen als alte Nachrichten.

    [Bearbeiten Verschönerung: Microsoft erkannte, dass dieses "Internet-Ding" eine große Sache war. Ihre technischen Fahrplan hat sich drastisch geändert, um den Fokus auf Internet Explorer, Windows Server, IIS, ASP, SQL-Server, COM/DCOM, Distributed Transaction Server. Damit das Dokument Linking and Embedding war nicht mehr eine hohe Priorität.]

    Den riesigen Fußabdruck von MFC machten es unmöglich für Sie, zu stürzen, so ist es dennoch entwickelt sich nur langsam. Vorlagen eingearbeitet wurden wieder in die Bibliothek, als auch die andere Sprache und API-Erweiterungen. (Ich hatte nicht gehört der WTL bis ich sah, diese Frage. 🙂

    Letztlich, welche zu verwenden ist einfach eine Frage der Präferenz. Die Mehrheit der Funktionen, die Sie brauchen, sind in der Basis-OS-API, die Sie aufrufen können entweder direkt aus der Bibliothek, wenn es keine geeignete wrapper in der Bibliothek.

    Nur meine 2 cents, basierend auf der Verwendung von MFC für viele Jahre, und ich benutze es jetzt täglich. Ich versuchte mich in ATL, als es zuerst veröffentlicht wurde, auf ein paar Projekte, die für ein paar Jahre. Es war ein Hauch frischer Luft in diesen Tagen, aber ging nie wirklich überall. Und dann das Web kam und ich es vergessen.

    Edit: Diese Antwort hat überraschende Langlebigkeit. Da es taucht immer wieder in meinen stack overflow Seite, ich dachte, ich würde hinzufügen, einige Verschönerung, die original-Antwort, die ich dachte, fehlte.

    InformationsquelleAutor der Antwort Jay

  2. 14

    Mir wurde gesagt, von vielen Menschen, die verwendet haben, dass Ihre Programmier-Erfahrung war weniger schmerzhaft mit der ATL als mit MFC. Ihre kompilierte ausführbare Datei auch viel kleiner, mit ATL.

    Empfehle ich Ihnen werfen Sie einen Blick auf WTLwie es baut auf ATL.

    Was ist das "zusätzliche Funktionalität" Sie halten erwähnen? Brauche ich es?

    Wenn Ihnen Ihre Anforderungen zu definieren, wäre es vielleicht einfacher zu beantworten, wenn Sie können, vermeiden Sie die Verwendung von MFC. Leider "nichts besonderes" ist nicht exklusiv genug. Einschließt, welche Merkmale die Sie verwenden möchten, hilfreich ist (die steuert, welche frameworks/Technologien/Bibliotheken, die Sie verwenden möchten, etc).

    Aber hier ist ein Artikel, der beschreibt einige Funktionen in der MFC, die nicht direkt unterstützt werden, indem WTL/ATL.

    MFC hat auch bis zu dem Punkt entwickelt, es unterstützt sehr viele wünschenswerte Funktionen, wie MAPI, Unterstützung für andere Windows-logo-Anforderungen, Fassungen, Dokumente (wenn Sie mögen und/oder nutzen Sie das Muster), und compound-Dokument-Dateien. WTL hat seinen Anteil an coolen features, aber MFC ist die klare Funktion champ. Beide Umgebungen unterstützen gerahmt Hauptfenster Architekturen (frame-Fenster mit separatem Fenster anzeigen), SDI-und MDI-Anwendungen, geteilte Fenster, Dialogfeld-basierte Anwendungen, sowie verschiedene COM-basierte Klassen für die COM-Unterstützung.

    InformationsquelleAutor der Antwort Merlyn Morgan-Graham

  3. 7

    ATL ist ein Satz von Klassen gemeint, vereinfachen die Implementierung von COM-Objekten.

    Können Sie es verwenden, ohne MFC. In meinem job, wir verwenden Sie ATL aussetzen COM-Schnittstellen computational code. Es gibt keine GUI beteiligt ist, ist es für uns, in der Lage, dieser Aufforderung computational code von zB. Excel-VBA.

    Blick auf einige COM-Anleitung/tutorial, um zu sehen, was es abstracts.

    MFC ist nur ein Satz von GUI-wrapper-Klassen, Win32-API. Blick auf einige Win32-API-tutorial, um zu sehen, was es abstracts.

    InformationsquelleAutor der Antwort Alexandre C.

Schreibe einen Kommentar