Jaka jest podstawowa różnica między MFC a ATL?

Zakładając, że używam ich tylko w "normalnych" programach GUI (bez COM, bez ActiveX, nic nadzwyczajnego), jaka jest podstawowa różnica, jaką zobaczę między ATL i MFC, aby pomóc mi dowiedzieć się, którego użyć?

Przeprowadziłem kilka wyszukiwań w Internecie, ale ostatecznie żadna z odpowiedzi tak naprawdę nie odpowiedziała na moje pytanie:

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

  • „ATL to szybki i łatwy sposób zarówno tworzenia komponentu COM w C ++, jak i zajmowania niewielkiej przestrzeni. Użyj ATL, aby utworzyć formant, jeśli nie potrzebujesz wszystkich wbudowanych funkcji, które MFC zapewnia automatycznie”.

    Tak naprawdę nie odpowiada na moje pytanie, ponieważ:

    • Nie pracuję z COM.

    • Czy to oznacza, że ​​MFC nie jest szybki? Dlaczego / jak?

  • „MFC umożliwia tworzenie pełnych aplikacji, formantów ActiveX i aktywnych dokumentów. Jeśli formant został już utworzony za pomocą MFC, możesz chcieć kontynuować rozwój w MFC. Tworząc nowy formant, rozważ użycie ATL, jeśli nie potrzebujesz wszystkie wbudowane funkcje MFC ”.

    Nie odpowiada też na moje pytanie, ponieważ:

    • Tak naprawdę nie wiem nawet, czym jest ActiveX w pierwszej kolejności.

    • Wygląda na to, że Microsoft zniechęca do korzystania z MFC, ale nie wiem, dlaczego.

    • Czym dokładnie jest „wbudowana funkcjonalność” MFC, której nie zapewnia ATL?

  • Ogólnie to nie odpowiada na moje pytanie, ponieważ nie wyjaśnia wad i przyczyn ich powstania.

ponieważ bezpośrednio lub pośrednio wszystko wydaje się odnosić do poprzedniej strony:

• Jak zdecydować, czy użyć ATL, MFC, Win32 lub CLR dla nowego projektu C ++?

  • „ATL i MFC są nieco trudniejsze do wyboru. [[Bez żartów!]] Skierowałbym cię na stronę MSDN w celu dokonania wyboru między nimi”.

    Oczywiście to nie odpowiada na moje pytanie. :)

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

• itp.

Co obecnie zaobserwowałem (w ciągu ostatnich kilku dni, próbując nauczyć się obu):

• ATL jest oparty na szablonach lub polimorfizmie w czasie kompilacji.
  • Metody ATL są zwykle niewirtualne i zwracają odwołania.
• MFC opiera się na metodach wirtualnych lub polimorfizmie w czasie wykonywania.
  • Metody MFC są zwykle wirtualne i zwracają wskaźniki.

Ale wydaje się, że nie ma między nimi żadnej różnicy architektonicznej :

• Oba używają map wiadomości ( BEGIN_MSG_MAPa BEGIN_MESSAGE_MAP... wielka sprawa)
• Obie zawijają metody Win32 w klasy
• Oba wydają się mieć podobne klasy CWndvs.CWindow

Ale jeśli nie ma prawdziwej różnicy poza aspektem czasu kompilacji i czasu wykonywania, to dlaczego oba one istnieją? Czy jeden z nich nie powinien wystarczyć?

Czego tu brakuje?

Myślę, że odpowiedź na twoje pytanie jest w większości historyczna, jeśli spojrzysz wstecz na to, jak obie biblioteki powstały i ewoluowały w czasie.

Krótka odpowiedź brzmi: jeśli nie robisz nic „wymyślnego”, użyj ATL. Świetnie nadaje się do prostych interfejsów użytkownika z wrzuconym COM.

Długa odpowiedź: MFC został zbudowany na początku lat 90., aby wypróbować nowy język o nazwie C ++ i zastosować go w systemie Windows. Dzięki temu funkcje podobne do pakietu Office były dostępne dla społeczności programistów, gdy system operacyjny jeszcze ich nie miał.

[Edytuj ozdoby: nie pracowałem w firmie Microsoft, więc nie wiem, czy pakiet Office został kiedykolwiek zbudowany na MFC, ale myślę, że odpowiedź brzmi: nie. Po powrocie do Win 3.1, Win 95 dni, zespół Office UI wymyślał nowe kontrolki, pakował je w biblioteki, a następnie zespoły Windows i MFC włączały opakowania i API do tych kontrolek za pomocą redystrybucyjnych bibliotek dll. Wydaje mi się, że między tymi zespołami było trochę współpracy i współdzielenia kodu. Ostatecznie te elementy sterujące znalazłyby się w podstawowym systemie operacyjnym w dodatkach Service Pack lub w następnej wersji systemu Windows. Ten wzorzec był kontynuowany w przypadku Wstążki pakietu Office, która została dodana do systemu Windows jako składnik dodatkowy długo po dostarczeniu pakietu Office i jest teraz częścią systemu operacyjnego Windows.]

W tamtym czasie biblioteka była dość prymitywna, zarówno ze względu na język C ++ i nowy kompilator, jak i Microsoft rozbudowywał ją w miarę ewolucji pakietu Office.

Z powodu tej historii MFC:

1. Ma dość niezgrabny projekt. Zaczęło się jako lekkie opakowanie wokół interfejsu API systemu Windows, ale wzrosło. Jest kilka małych „funkcji”, które trzeba było wymyślić, ponieważ kompilator i język po prostu ich nie obsługiwały. Nie było szablonów, wymyślili klasę ciągów, wymyślili klasy list, zaprojektowali własną identyfikację typu w czasie wykonywania itp.
2. Zawiera 20 lat ewolucji pakietu Office i Windows, w tym całą masę rzeczy, których prawdopodobnie nigdy nie będziesz używać: interfejsy pojedynczego i wielu dokumentów, DDE, COM, COM +, DCOM, łączenie dokumentów i osadzanie (dzięki czemu możesz osadzić dokument Word w Twoja aplikacja, jeśli chcesz), formanty ActiveX (ewolucja osadzania obiektów w sieci!), strukturalne przechowywanie dokumentów, serializacja i wersjonowanie, automatyzacja (z wczesnych lat VBA) i oczywiście MVC. Najnowsze wersje obsługują dokowanie okien w stylu programu Visual Studio i wstążkę pakietu Office. W zasadzie każda technologia z Redmond w ciągu 20 lat jest gdzieś tam. To po prostu OGROMNE!
3. Ma mnóstwo drobnych pułapek, błędów, obejść, założeń, wsparcia dla rzeczy, które wciąż istnieją, których nigdy nie będziesz używać i powodują problemy. Musisz być dokładnie zaznajomiony z implementacją wielu klas i ich interakcjami, aby używać ich w projekcie o przyzwoitej wielkości. Zagłębianie się w kod źródłowy MFC podczas debugowania jest powszechne. Znalezienie 15-letniej notatki technicznej na którymś wskaźniku jest zerowa, co powoduje awarię. Założenia dotyczące inicjalizacji starożytnych elementów osadzania dokumentów mogą wpływać na twoją aplikację w dziwny sposób. W MFC nie ma czegoś takiego jak abstrakcja, musisz codziennie pracować z jej dziwactwami i elementami wewnętrznymi, to niczego nie ukrywa. I nie zaczynaj od klasowego kreatora.

ATL został wynaleziony w miarę ewolucji języka C ++ i pojawiły się szablony. ATL był przykładem korzystania z szablonów, aby uniknąć problemów z biblioteką MFC w czasie wykonywania:

1. Mapy komunikatów: ponieważ są oparte na szablonach, typy są sprawdzane, a jeśli schrzanisz powiązaną funkcję, nie zostanie ona zbudowana. W MFC mapy komunikatów są oparte na makrach i powiązane z czasem wykonywania. Może to spowodować dziwne błędy, wiadomość skierowaną do niewłaściwego okna, awarię, jeśli masz nieprawidłowo zdefiniowaną funkcję lub makro lub po prostu nie zadziała, ponieważ coś nie jest poprawnie podłączone. Znacznie trudniejszy do debugowania i łatwiejszy do złamania bez zauważenia.
2. COM / Automation: Podobnie jak mapy komunikatów, COM był pierwotnie związany z czasem wykonywania przy użyciu makr, co wymagało obsługi wielu błędów i powodowało dziwne problemy. ATL uczynił go opartym na szablonie, ograniczonym czasem kompilacji i dużo, dużo łatwiejszym w obsłudze.

[Edytuj upiększenie: W czasie tworzenia ATL, techniczna mapa drogowa Microsoftu koncentrowała się głównie na „Zarządzaniu dokumentami”. Apple zabijał ich w branży DTP. Office „Document Linking and Embedding” był głównym składnikiem udoskonalenia funkcji Office Document Management w celu konkurowania w tej przestrzeni. COM był podstawową technologią wymyśloną do integracji aplikacji, a interfejsy API osadzania dokumentów były oparte na modelu COM. MFC było trudne w użyciu w tym przypadku użycia. ATL było dobrym rozwiązaniem, które ułatwiło firmom trzecim wdrażanie modelu COM i wykorzystywanie funkcji osadzania dokumentów.]

Te drobne ulepszenia znacznie ułatwiają obsługę ATL w prostej aplikacji, która nie potrzebuje wszystkich funkcji biurowych, takich jak MFC. Coś z prostym interfejsem użytkownika i dorzuconą automatyzacją pakietu Office. Jest mały, szybki, wymaga czasu kompilacji, oszczędzając dużo czasu i bólu głowy. MFC ma ogromną bibliotekę klas, które mogą być niezgrabne i trudne w obsłudze.

Niestety ATL zatrzymał się. Miał opakowania dla obsługi Windows API i COM, ale nigdy tak naprawdę nie wykraczał poza to. Kiedy Internet wystartował, wszystko to zostało zapomniane jako stare wiadomości.

[Edytuj upiększenie: Microsoft zdał sobie sprawę, że ta „rzecz internetowa” będzie duża. Ich techniczna mapa drogowa zmieniła się drastycznie i skupiła się na Internet Explorer, Windows Server, IIS, ASP, SQL Server, COM / DCOM w Distributed Transaction Server. Dlatego łączenie i osadzanie dokumentów nie było już priorytetem.]

Ogromny ślad MFC uniemożliwił im zrzut, więc nadal rozwija się powoli. Szablony zostały ponownie włączone do biblioteki, a także inne ulepszenia języka i interfejsu API. (Nie słyszałem o WTL, dopóki nie zobaczyłem tego pytania. :)

Ostatecznie, którego z nich użyć, jest po prostu kwestią preferencji. Większość potrzebnych funkcji znajduje się w podstawowym interfejsie API systemu operacyjnego, który można wywołać bezpośrednio z dowolnej biblioteki, jeśli w bibliotece nie ma odpowiedniego opakowania.

Tylko moje 2 centy oparte na używaniu MFC przez wiele lat i używam go teraz codziennie. Parałem się ATL, kiedy został wydany po raz pierwszy w kilku projektach przez kilka lat. W tamtych czasach był to powiew świeżego powietrza, ale tak naprawdę nigdzie się nie udawał. A potem pojawił się Internet i zapomniałem o tym.

Edycja: ta odpowiedź ma zaskakującą długowieczność. Ponieważ ciągle pojawia się na mojej stronie przepełnienia stosu, pomyślałem, że dodam trochę ozdób do oryginalnej odpowiedzi, której moim zdaniem brakowało.

Wiele osób mówiło mi, że ich doświadczenie programistyczne było mniej bolesne z ATL niż z MFC. Twój skompilowany plik wykonywalny będzie również znacznie mniejszy z ATL.

Polecam przyjrzeć się WTL , ponieważ opiera się na ATL.

Co to za „dodatkowa funkcjonalność”, o której ciągle wspominają? Czy tego potrzebuję?

Jeśli zdefiniujesz swoje wymagania, łatwiej będzie odpowiedzieć, czy możesz uniknąć korzystania z MFC. Niestety „nic nadzwyczajnego” nie jest wystarczająco ekskluzywne. Uwzględnienie wszystkich funkcji, których zamierzasz użyć, może być bardziej pomocne (które kontrolują, jakich frameworków / technologii / istniejących bibliotek chcesz używać itp.).

Ale oto artykuł opisujący niektóre funkcje MFC, które nie są bezpośrednio obsługiwane przez WTL / ATL.

MFC również ewoluowało do tego stopnia, że ​​obsługuje wiele pożądanych funkcji, takich jak MAPI, obsługa innych wymagań dotyczących logo systemu Windows, gniazd, dokumentów (jeśli chcesz i / lub używasz tego wzorca) oraz złożonych plików dokumentów. WTL ma wiele fajnych funkcji, ale MFC jest wyraźnym mistrzem funkcji. Oba środowiska obsługują architekturę głównego okna z ramkami (okno ramkowe z oddzielnym oknem widoku), aplikacje SDI i MDI, okna podzielone, aplikacje oparte na oknach dialogowych oraz różne klasy oparte na modelu COM do obsługi COM.

ATL to zestaw klas, które mają uprościć implementację obiektów COM.

Możesz go używać bez MFC. W mojej pracy używamy ATL do udostępniania interfejsów COM do kodu obliczeniowego. Nie ma tam GUI, to dla nas jest możliwość wywołania tego kodu obliczeniowego z np. Excel VBA.

Zajrzyj do przewodnika / samouczka dotyczącego modelu COM, aby zobaczyć, co zawiera.

MFC to po prostu zestaw klas opakowania GUI do interfejsu API Win32. Zapoznaj się z samouczkiem dotyczącym interfejsu API Win32, aby zobaczyć, co zawiera.