c++ visual - Was ist der grundlegende Unterschied zwischen MFC und ATL?





studio download (4)


ATL ist eine Menge von Klassen, die die Implementierung von COM-Objekten vereinfachen sollen.

Sie können es ohne MFC verwenden. In meinem Job verwenden wir ATL, um COM-Schnittstellen mit Rechencode zu versehen. Es gibt keine GUI, es ist für uns möglich, diesen Rechencode von z. Excel VBA.

Sehen Sie sich einige COM-Anleitungen an, um zu sehen, was sie abstrahieren.

MFC ist nur eine Gruppe von GUI-Wrapper-Klassen für die Win32-API. Sehen Sie sich Win32-API-Tutorial an, um zu sehen, was es abstrahiert.

Angenommen, ich benutze sie nur für "normale" GUI-Programme (kein COM, kein ActiveX, nichts Besonderes), was ist der grundlegende Unterschied, den ich zwischen ATL und MFC sehen werde, um mir zu helfen, herauszufinden, welche zu verwenden?

Ich habe einige Suchen im Internet durchgeführt, aber letztendlich hat keine der Antworten meine Frage wirklich beantwortet:

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

    • "ATL ist eine schnelle, einfache Möglichkeit, eine COM-Komponente in C ++ zu erstellen und einen geringen Platzbedarf zu bewahren. Verwenden Sie ATL, um ein Steuerelement zu erstellen, wenn Sie nicht alle integrierten Funktionen benötigen, die MFC automatisch bereitstellt."

      Beantwortet meine Frage nicht wirklich, denn:

      • Ich arbeite nicht mit COM.

      • Bedeutet das, MFC ist nicht schnell? Warum wie?

    • "MFC ermöglicht es Ihnen, vollständige Anwendungen, ActiveX-Steuerelemente und aktive Dokumente zu erstellen. Wenn Sie bereits ein Steuerelement mit MFC erstellt haben, möchten Sie möglicherweise die Entwicklung in MFC fortsetzen. Wenn Sie ein neues Steuerelement erstellen, sollten Sie ATL verwenden, wenn Sie nicht benötigen alle integrierten Funktionen von MFC. "

      Beantwortet auch meine Frage nicht, weil:

      • Ich weiß nicht wirklich, was ActiveX überhaupt ist .

      • Es sieht so aus, als ob Microsoft die Verwendung von MFC entmutigt, aber ich kann nicht herausfinden, warum.

      • Was genau ist MFCs "eingebaute Funktionalität", die ATL nicht bietet?

    • Im Allgemeinen beantwortet das meine Frage nicht, weil es nicht die Nachteile und die Gründe dafür erklärt.

weil direkt oder indirekt alles auf die vorherige Seite zurückzuführen scheint:

Was ich gerade beobachtet habe (in den letzten Tagen, als ich versuchte beides zu lernen):

  • ATL basiert auf Vorlagen oder kompilierbarer Polymorphie.
    • ATL-Methoden neigen dazu, nicht virtuell zu sein, und neigen dazu, Referenzen zurückzugeben.
  • MFC basiert auf virtuellen Methoden oder Laufzeitpolymorphismus.
    • MFC-Methoden neigen dazu, virtuell zu sein, und neigen dazu, Zeiger zurückzugeben.

Aber es scheint keinen architektonischen Unterschied zwischen ihnen zu geben :

  • Beide verwenden Nachrichtenkarten ( BEGIN_MSG_MAP vs. BEGIN_MESSAGE_MAP ... große Sache)
  • Beide umhüllen Win32-Methoden in Klassen
  • Beide scheinen ähnliche Klassen CWnd vs. CWindow

Aber wenn es keinen wirklichen Unterschied gibt, außer für den Kompilierungszeit- und Laufzeitaspekt, warum gibt es dann beide? Sollte einer von ihnen nicht genug sein?

Was fehlt mir hier?




Viele Leute haben mir gesagt, dass ihre Programmiererfahrung bei ATL weniger schmerzhaft war als bei MFC. Ihre kompilierte ausführbare Datei wird auch mit ATL viel kleiner sein.

Ich empfehle Ihnen , sich WTL anzusehen , da es auf ATL aufbaut.

Was ist diese "zusätzliche Funktionalität", die sie immer wieder erwähnen? Brauche ich es?

Wenn Sie Ihre Anforderungen definieren, ist es möglicherweise einfacher zu beantworten, wenn Sie die Verwendung von MFC vermeiden können. Leider ist "nichts Schickes" nicht exklusiv genug. Es kann hilfreicher sein, zu überlegen, welche Funktionen Sie verwenden möchten (welche Steuerelemente, welche Frameworks / Technologien / vorhandenen Bibliotheken Sie verwenden möchten usw.).

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

MFC hat sich auch zu dem Punkt entwickelt, dass es eine Vielzahl von wünschenswerten Funktionen unterstützt, wie MAPI, Unterstützung für die anderen Windows-Logoanforderungen, Sockets, Dokumente (wenn Sie dieses Muster mögen und / oder verwenden) und zusammengesetzte Dokumentdateien. WTL hat einige coole Features, aber MFC ist der klare Feature-Champion. Beide Umgebungen unterstützen gerahmte Hauptfensterarchitekturen (Rahmenfenster mit separatem Sichtfenster), SDI- und MDI-Anwendungen, geteilte Fenster, dialogbasierte Anwendungen und verschiedene COM-basierte Klassen für die COM-Unterstützung.




Ich denke, die Antwort auf Ihre Frage ist meist historisch, wenn Sie zurückblicken, wie die beiden Bibliotheken entstanden sind und sich im Laufe der Zeit entwickelt haben.

Die kurze Antwort ist, wenn Sie nichts "Phantasie" tun, ATL verwenden. Es ist großartig für einfache Benutzeroberflächen mit COM in geworfen.

Die lange Antwort: MFC wurde in den frühen 90er Jahren gebaut, um diese neue Sprache namens C ++ auszuprobieren und auf Windows anzuwenden. Es machte Office-ähnliche Funktionen für die Entwicklergemeinschaft verfügbar, wenn das Betriebssystem sie noch nicht hatte.

[Edit Verschönerung: Ich habe nicht bei Microsoft gearbeitet, also weiß ich nicht, ob Office jemals auf MFC gebaut wurde, aber ich denke, die Antwort ist nein. Zurück in Win 3.1, Windows 95 Tage, würde das Office UI-Team neue Steuerelemente erfinden und sie in Bibliotheken verpacken. Dann würden die Windows- und MFC-Teams Wrapper und API in diese Steuerelemente mit verteilbaren DLLs integrieren. Ich denke, es gab ein bisschen Zusammenarbeit und Code-Sharing zwischen diesen Teams. Schließlich würden diese Steuerelemente in Service Packs oder der nächsten Windows-Version in das Basisbetriebssystem übergehen. Dieses Muster wurde mit dem Office-Menüband fortgesetzt, das nach der Auslieferung von Office als Add-On-Komponente in Windows hinzugefügt wurde und nun Teil des Windows-Betriebssystems ist.]

Zu dieser Zeit war die Bibliothek ziemlich primitiv, sowohl wegen der C ++ - Sprache und des Compilers, die neu waren, als auch während der Entwicklung von Office durch Microsoft.

Wegen dieser Geschichte, MFC:

  1. Hat ein ziemlich klobiges Design. Es begann als leichter Wrapper um die Windows-API, wuchs aber. Es gibt eine Menge kleiner "Features", die erfunden werden mussten, weil der Compiler und die Sprache sie einfach nicht unterstützten. Es gab keine Vorlagen, sie erfanden eine String-Klasse, sie erfanden Listen-Klassen, sie entwarfen ihre eigene Laufzeit-Typ-Identifikation usw.
  2. Verkapselt 20 Jahre Office- und Windows-Entwicklung, die eine ganze Menge von Dingen enthält, die Sie wahrscheinlich nie benutzen werden: Einzel- und Mehrfachdokument-Schnittstellen, DDE, COM, COM +, DCOM, Dokumentenverknüpfung und -einbettung (damit Sie ein Word-Dokument einbetten können) Ihre App, wenn Sie wollten), ActiveX-Steuerelemente (Evolution der Objekteinbettung für das Web!), Strukturierte Dokumentenspeicherung, Serialisierung und Versionierung, Automatisierung (aus frühen VBA-Jahren) und natürlich MVC. Die neuesten Versionen unterstützen das Andocken von Visual Studio-Stilfenster und das Office-Menüband. Grundsätzlich ist jede Technologie aus Redmond in 20 Jahren irgendwo drin. Es ist einfach riesig!
  3. Hat eine Tonne kleiner Fehler, Fehler, Umgehungslösungen, Annahmen, Unterstützung für Dinge, die immer noch da sind, die Sie nie benutzen werden, und sie verursachen Probleme. Sie müssen sehr vertraut mit der Implementierung vieler Klassen sein und wie sie interagieren, um sie bei einem anständigen Projekt zu verwenden. Es ist üblich, MFC-Quellcode während des Debuggens zu verwenden. Das Finden einer 15 Jahre alten Tech-Notiz über einen Zeiger, der null ist und einen Absturz verursacht, passiert immer noch. Annahmen bei der Initialisierung von Dokumenteneinbettungen können Ihre Anwendung auf seltsame Weise beeinflussen. Es gibt keine Abstraktion in MFC, man muss täglich mit seinen Macken und Interna arbeiten, es verbirgt nichts. Und lass mich nicht mit dem Klassenassistenten anfangen.

ATL wurde erfunden, als sich die C ++ - Sprache entwickelte und Vorlagen eintrafen. ATL war ein Schaufenster der Verwendung von Vorlagen, um die Laufzeitprobleme der MFC-Bibliothek zu vermeiden:

  1. Message-Maps: Da sie Template-basiert sind, werden Typen überprüft, und wenn Sie die gebundene Funktion vermasseln, wird sie nicht erstellt. In MFC-Nachrichtenzuordnungen sind Makro und Laufzeit gebunden. Dies kann zu seltsamen Fehlern führen, eine Nachricht wird an das falsche Fenster weitergeleitet, ein Absturz, wenn Sie eine Funktion oder ein Makro falsch definiert haben oder einfach nicht funktionieren, weil etwas nicht richtig angeschlossen ist. Viel schwieriger zu debuggen, und einfacher zu brechen, ohne es zu merken.
  2. COM / Automation: Ähnlich wie Nachrichtenzuordnungen wurde COM ursprünglich mit Makros run-time gebunden, was zu vielen Fehlern führte und zu seltsamen Problemen führte. ATL hat es vorlagenbasiert, kompilierzeitgebunden und viel, viel einfacher zu handhaben.

[Bearbeiten Verschönerung: Zum Zeitpunkt der Erstellung von ATL konzentrierte sich die technische Roadmap von Microsoft hauptsächlich auf das "Dokumentenmanagement". Apple hat sie im Desktop-Publishing-Geschäft getötet. Office "Dokumentenverknüpfung und -einbettung" war eine Hauptkomponente zur Verbesserung der "Dokumentenmanagement" -Funktionen von Office, um in diesem Bereich wettbewerbsfähig zu sein. COM war eine Kerntechnologie, die für die Anwendungsintegration erfunden wurde, und Dokumenteinbettungs-APIs basierten auf COM. MFC war schwierig für diesen Anwendungsfall zu verwenden. ATL war eine gute Lösung, um diese spezielle Technologie für Drittanbieter einfacher zu machen, COM zu implementieren und Dokumenteinbettungsfunktionen zu verwenden.]

Diese kleinen Verbesserungen machen ATL enorm einfacher in einer einfachen Anwendung, die nicht alle Office-ähnlichen Features von MFC benötigt. Etwas mit einer einfachen Benutzeroberfläche und etwas Office-Automatisierung. Es ist klein, es ist schnell, es ist kompiliert Zeit sparen Sie viel Zeit und Kopfschmerzen. MFC verfügt über eine riesige Bibliothek mit Klassen, die schwerfällig und schwer zu bearbeiten sind.

Leider stagnierte ATL. Es hatte Wrapper für die Windows-API und COM-Unterstützung, und dann ging es nie wirklich darüber hinaus. Als das Web abhob, war all das Zeug in Vergessenheit geraten wie alte Nachrichten.

[Bearbeiten Verschönerung: Microsoft erkannte, dass dieses 'Internet Ding' groß sein würde. Ihre technische Roadmap wurde drastisch geändert, um sich auf Internet Explorer, Windows Server, IIS, ASP, SQL Server und COM / DCOM in Distributed Transaction Server zu konzentrieren. Die Dokumentverknüpfung und -einbettung hatte daher keine hohe Priorität mehr.]

Der riesige Footprint von MFC machte es unmöglich, sie zu löschen, also entwickelt sie sich immer noch langsam. Vorlagen wurden wieder in die Bibliothek integriert, ebenso wie andere Sprach- und API-Erweiterungen. (Ich hatte noch nicht von WTL gehört, bis ich diese Frage sah :)

Letztendlich ist es einfach eine Frage der Präferenz, welche zu verwenden ist. Die meisten Funktionen, die Sie benötigen, befinden sich in der Basis-OS-API, die Sie direkt aus jeder Bibliothek aufrufen können, wenn sich in der Bibliothek kein geeigneter Wrapper befindet.

Nur meine 2 Cent basieren auf MFC für viele Jahre, und ich benutze es jetzt täglich. Ich habe mich bei ATL versucht, als es bei einigen Projekten für ein paar Jahre veröffentlicht wurde. Es war damals ein frischer Wind, aber ging nie wirklich irgendwohin. Und dann kam das Web und ich habe alles vergessen.

Edit: Diese Antwort hat eine überraschende Langlebigkeit. Da es in meiner Stack-Überlauf-Seite immer wieder auftaucht, dachte ich, ich würde der ursprünglichen Antwort, die mir fehlte, etwas hinzufügen.




Ein weiterer Unterschied ist, dass Sie Zeiger auf einen ungültigen Typ haben können (und zwar Zeiger auf irgendetwas), aber Verweise auf ungültig sind verboten.

int a;
void * p = &a; // ok
void & p = a;  //  forbidden

Ich kann nicht sagen, dass ich mit diesem besonderen Unterschied wirklich glücklich bin. Ich würde es sehr vorziehen, wenn die Bedeutung der Referenz auf alles mit einer Adresse und sonst das gleiche Verhalten für Referenzen erlaubt wäre. Damit könnten einige Äquivalente von C-Bibliotheksfunktionen wie memcpy unter Verwendung von Referenzen definiert werden.





c++ visual-c++ mfc atl