Яка принципова відмінність між MFC та ATL?


110

Якщо припустити, що я використовую їх лише для "звичайних" програм GUI (немає COM, немає ActiveX, нічого фантазійного), яка принципова різниця я побачу між ATL та MFC, щоб допомогти мені зрозуміти, яку з них використовувати?


Я здійснив кілька пошукових запитів в Інтернеті, але в кінцевому підсумку жодна з відповідей не відповіла на моє запитання:

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

    • "ATL - це швидкий і простий спосіб як створити COM-компонент в C ++, так і підтримувати невеликий слід. Використовуйте ATL для створення елемента управління, якщо вам не потрібен весь вбудований функціонал, який MFC автоматично надає."

      Насправді не відповідає на моє запитання, оскільки:

      • Я не працюю з COM.

      • Це означає, що MFC не швидкий? Чому / як?

    • "MFC дозволяє створювати повноцінні програми, елементи керування ActiveX та активні документи. Якщо ви вже створили елемент керування за допомогою MFC, можливо, ви захочете продовжити розробку в MFC. Створюючи новий елемент управління, подумайте про використання ATL, якщо вам це не потрібно весь вбудований функціонал MFC. "

      Також не відповідає на моє запитання, оскільки:

      • Я не знаю , що навіть ActiveX є в першу чергу.

      • Схоже, Microsoft заважає використовувати MFC, але я не можу зрозуміти, чому.

      • Що саме є "вбудованою функціональністю" MFC, яку ATL не надає?

    • Взагалі це не відповідає на моє запитання, оскільки це не пояснює недоліки та причини, що їх викликають.

тому що прямо або опосередковано все, схоже, посилається на попередню сторінку:

Що я зараз спостерігав (протягом останніх кількох днів, намагаючись навчитися обох):

  • ATL заснований на шаблонах або поліморфізмі під час компіляції.
    • Методи ATL, як правило, не віртуальні, і як правило, повертають посилання.
  • MFC заснований на віртуальних методах, або поліморфізмі під час виконання.
    • Методи MFC мають тенденцію бути віртуальними та мають тенденцію до повернення покажчиків.

Але , схоже, між ними немає ніякої архітектурної різниці :

  • Обидва використовують карти повідомлень ( BEGIN_MSG_MAPпорівняно BEGIN_MESSAGE_MAP... велика справа)
  • Обидва способи переносять Win32 у класи
  • Здається, обидва мають схожі класи CWndпротиCWindow

Але тоді, якщо немає ніякої реальної різниці, крім аспекту компіляції та часу виконання, то чому вони існують? Невже одного з них не вистачить?

Що я тут пропускаю?


3
Я можу помилятися, але я знаю, що MFC вимагає дещо здоровенного DLL часу виконання, тоді як я думаю, що ATL об'єднує все в один екзе. АТЛ загалом легша. Також перевіряйте WTL
Merlyn Morgan-Graham

@Merlyn: Правильно, але навіщо вона потребує здорової DLL часу виконання? Яка принципова відмінність викликає це?
користувач541686

1
Однакова різниця між успадковуванням попередньо складених класів, пов'язаних з DLL, і спадковими шаблонами, пов'язаними за допомогою включення вихідного коду / інстанції шаблону. Шаблони, як правило, "бібліотеки" лише для заголовка. Моя відповідь неповна, отже, у коментарях :) MFC все ще існує через величезне прийняття та зворотну сумісність. Інакше MS викинуло б це, коли створили новіші обгортки win32. Вони, як правило, мають тривалі контракти на підтримку свого програмного забезпечення (різні, але до 10 років). Підтримка не сумісна з депресією, тхо.
Мерлін Морган-Грехем

@Merlyn: То я розумію, що я не повинен використовувати MFC? Що це за «додаткова функціональність», яку вони постійно згадують? Мені це потрібно?
користувач541686

2
@Merlyn: Чув про ATL.DLL? Чули термін "Використовувати MFC як статичну бібліотеку"?
Аджай

Відповіді:


179

Я думаю, що відповідь на ваше запитання здебільшого є історичною, якщо поглянути на те, як дві бібліотеки зароджувались та розвивались у часі.

Коротка відповідь - якщо ви нічого не робите «фантазії», використовуйте ATL. Це чудово підходить для простих користувальницьких інтерфейсів із вбудованим COM

Довга відповідь: MFC був побудований на початку 90-х, щоб випробувати цю нову мову під назвою C ++ та застосувати її до Windows. Це зробило Office подібним до функцій, доступних спільноті розробників, коли ОС їх ще не мала.

[Редагувати прикраси: я не працював у Microsoft, тому не знаю, чи Office коли-небудь будувався на MFC, але я думаю, що відповідь - ні. Ще в програмі Win 3.1, Win 95 днів команда Office UI винайде нові елементи керування, пакує їх у бібліотеки, тоді команди Windows та MFC включатимуть обгортки та API для цих елементів управління з перерозподіленими dlls. Я б здогадався, що між цими командами було трохи співпраці та обміну кодом. Врешті-решт, ці елементи керування перетворять їх у базову операційну систему в пакетах послуг або наступній версії Windows. Ця закономірність продовжувалась із стрічкою Office, яка була додана в Windows як додатковий компонент після завантаження Office, і тепер є частиною ОС Windows.]

У той час бібліотека була досить примітивною, як через мову C ++, так і для компілятора, і Microsoft створював її з часом, коли Office розвивався.

Через цю історію MFC:

  1. Має досить незграбний дизайн. Він розпочався як легка обгортка навколо API Windows, але зростав. Є купа маленьких "функцій", які довелося винайти, оскільки компілятор і мова просто не підтримували їх. Не було шаблонів, вони винайшли клас рядків, вони винайшли класи списків, створили власну ідентифікацію типу часу виконання тощо.
  2. Інкапсулює 20 років розвитку Office та Windows, що включає цілий набір матеріалів, які ви, ймовірно, ніколи не будете використовувати: Інтерфейси одного та декількох документів, DDE, COM, COM +, DCOM, Зв'язування та вбудовування документів (так що ви можете вставляти документ із слів у ваш додаток, якщо ви цього хотіли), ActiveX управління (еволюція вбудовування об’єктів для Інтернету!), структуроване зберігання документів, серіалізація та версії, автоматизація (з ранніх років VBA) і звичайно MVC. В останніх версіях підтримується стикування вікон у стилі Visual Studio та стрічка Office. В основному кожна технологія, що виходить за Редмонда за 20 років, є десь там. Це просто ВЕЛИЧЕЗНО!
  3. Має безліч дрібниць, помилок, шляхів вирішення проблем, припущень, підтримки речей, які все ще є, які ви ніколи не використаєте, і вони створюють проблеми. Вам потрібно добре ознайомитись із реалізацією багатьох класів та способами їх взаємодії, щоб використовувати її у проекті пристойного розміру. Поглиблення у вихідний код MFC під час налагодження є загальним явищем. Виявлення 15-річної технічної записки на якомусь вказівнику недійсним викликає збій. Припущення про ініціалізацію стародавнього вбудовування матеріалів можуть впливати на вашу програму дивними способами. У MFC немає такого поняття, як абстракція. Вам потрібно щодня працювати з химерностями та внутрішніми характеристиками, це нічого не приховує. І не запускайте мене до майстра класу.

ATL був винайдений з розвитком мови C ++ і надходженням шаблонів. ATL - це демонстрація того, як використовувати шаблони, щоб уникнути проблем із запуском бібліотеки MFC:

  1. Карти повідомлень: Оскільки вони засновані на шаблонах, типи перевіряються, і якщо ви вкручуєте пов'язану функцію, вона не створюється. У картках MFC-карти на основі макроса та часу виконання. Це може викликати непарні помилки, повідомлення, перенаправлене в неправильне вікно, збій, якщо функція чи макрос визначені неправильно, або просто не працюють, тому що щось не підключено правильно. Набагато складніше налагоджувати, і легше зламати, не помічаючи.
  2. COM / Автоматизація: Подібно до карт повідомлень, COM спочатку виконував час роботи за допомогою макросів, вимагаючи багато передачі помилок та спричинення незвичайних проблем. ATL зробила його на основі шаблонів, склав обмежений час і багато, набагато простіше для вирішення.

[Редагувати прикрасу: На час створення ATL технічна дорожня карта Майкрософт була зосереджена в основному на «Управління документами». Apple вбивала їх у настільному видавничому бізнесі. Office "Зв'язування та вставлення документів" було головним компонентом для вдосконалення функцій "Управління документами" Office для конкуренції в цьому просторі. COM - основна технологія, придумана для інтеграції програм, а API вбудовування документів базувався на COM. MFC було важко використовувати для цього випадку використання. ATL було хорошим рішенням, щоб полегшити цю технологію сторонній стороні для впровадження COM та використання функцій вбудовування документів.]

Ці невеликі вдосконалення значно полегшують роботу з ATL у простому додатку, якому не потрібні всі офіси, як функції MFC. Щось із простим інтерфейсом користувача та деякою автоматизованою системою Office. Це невеликий, швидкий, компільований час, що заощаджує багато часу та головного болю. MFC має величезну бібліотеку класів, яка може бути незграбною та складною для роботи.

На жаль, ATL застоювався. Він мав обгортки для підтримки API API та COM, і тоді він ніколи не виходив за рамки цього. Коли Інтернет вилетів, усі ці речі були наче забуті як старі новини.

[Редагувати прикрасу: Microsoft зрозуміла, що ця "Інтернет-річ" буде великою. Їх технічна дорожня карта кардинально змінилася, зосередившись на Internet Explorer, Windows Server, IIS, ASP, SQL Server, COM / DCOM на сервері розподілених транзакцій. Тож зв'язування та вкладання документів вже не було пріоритетним завданням.]

Величезний слід MFC унеможливив їх скидання, тому він все ще розвивається повільно. Шаблони знову включені в бібліотеку, а також інші вдосконалення мови та API. (Я не чув про WTL, поки не побачив це питання. :)

Зрештою, який саме використовувати - це просто питання переваги. Більшість необхідних функцій знаходяться в базовому API API, до якого можна зателефонувати безпосередньо з будь-якої бібліотеки, якщо в бібліотеці немає відповідного обгортка.

Просто мої 2 копійки на основі використання MFC протягом багатьох років, і я використовую його щодня. Я посварився в ATL, коли він був вперше випущений у кількох проектах за пару років. В ті часи це було ковтоком свіжого повітря, але ніколи насправді нікуди не ходили. І тоді Мережа з'явилася, і я забув про це все.


Редагувати: Ця відповідь має дивовижне довголіття. Оскільки він постійно вискакує на моїй сторінці переповнення стека, я подумав, що додаю прикраси до оригінальної відповіді, яку, на мою думку, бракує.


39
+1 Я б хотів, щоб я міг +10 цього. Дякуємо за чудовий опис історії - це дуже добре написано та інформативно! :)
користувач541686

3
Просто хотів згадати ... Я кілька днів користувався MFC, потім перейшов на ATL / WTL, який я вже деякий час використовую. І це химерно дивовижно. Мабуть, ніколи більше не буду дивитися на MFC.
користувач541686,

1
Тож Microsoft будує нові програми, використовуючи обидві, або вони вирішили використовувати одну над іншою?
Людина-булочка

1
Я думав , що я знав , що difference..but ніколи не бачив такого красиве і розробити explanation..Thumbs up..Thanks тонни :)
Шівь

1
Найкраща відповідь, яку я коли-небудь читав на цю тему; ви повинні зробити статтю з неї, включаючи WTL
Пт

20

Мені сказали багато людей, які використали і те, що їх досвід програмування був менш болючим з ATL, ніж з MFC. Ваш компільований виконуваний файл також буде значно меншим за ATL.

Я рекомендую вам поглянути на WTL , оскільки він базується на ATL.

Що це за «додаткова функціональність», яку вони постійно згадують? Мені це потрібно?

Якщо ви визначаєте свої вимоги, може бути простіше відповісти, чи не можете ви використовувати MFC. На жаль, "нічого фантазійного" недостатньо ексклюзивно. Інклюзивність щодо того, які функції ви плануєте використовувати, може бути кориснішою (які елементи керування, які рамки / технології / існуючі бібліотеки ви хочете використовувати тощо).

Але ось стаття, яка описує деякі функції в MFC, які не підтримуються безпосередньо WTL / ATL.

MFC також розвинувся до того, що він підтримує безліч бажаних функцій, таких як MAPI, підтримка інших вимог логотипу Windows, розетки, документи (якщо ви любите та / або використовуєте цей зразок) та складні файли документів. WTL має частку прикольних функцій, але MFC - це чітка функція. Обидва середовища підтримують структуровані основні вікна архітектури (вікно кадру з окремим вікном перегляду), додатки SDI та MDI, розділені вікна, додатки на основі діалогів та різні класи на основі COM для підтримки COM.


3
Відповідь Джея перемогла це. Залишаючи це за посиланням на статтю, що пояснює деякі відмінності.
Мерлін Морган-Грехем

9

ATL - це набір класів, призначений для спрощення реалізації об'єктів COM.

Ви можете використовувати його без MFC. На моїй роботі ми використовуємо ATL, щоб виставити COM-інтерфейси обчислювальному коду. Ніякого графічного інтерфейсу не задіяно, саме ми можемо викликати цей обчислювальний код, наприклад. Excel VBA.

Погляньте на деякий посібник / підручник із COM, щоб побачити, що вони резюмують.

MFC - це лише набір класів обгортки GUI для API Win32. Подивіться підручник з API Win32, щоб побачити, що він резюмує.


ATL також можна використовувати без участі COM. Багато класів у ньому не мають відношення до COM, що стає ще більш вираженим при погляді на WTL.
0xC0000022L

1
@ 0xC0000022L: Мені не було відомо CWindowImplі друзі, коли я писав це. Тепер, коли у мене є більше досвіду роботи з ATL, я можу спробувати переписати цю відповідь. Зокрема, ATL / WTL може практично замінити весь MFC.
Олександр К.
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.