В чем принципиальная разница между MFC и ATL?

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

короткий ответ: если вы не делаете ничего "причудливого", используйте ATL. Он отлично подходит для простых пользовательских интерфейсов с COM.

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

[Edit embellishment: я не работал в Microsoft, поэтому я не знаю, был ли Office когда-либо построен на MFC, но я думаю, что ответ нет. В Win 3.1, Win 95 days, команда Office UI будет изобретать новые элементы управления, упаковывать их в библиотеки, а затем команды Windows и MFC будут включать обертки и API для этих элементов управления с распространяемыми библиотеками DLL. Я бы предположил, что между этими командами было немного сотрудничества и совместного использования кода. В конце концов те элементы управления сделают его базовой операционной системой в пакетах обновления или следующей версии Windows. Этот шаблон продолжался с лентой Office, которая была добавлена в Windows в качестве дополнительного компонента после отправки Office и теперь является частью ОС Windows.]

в то время библиотека была довольно примитивной, как из-за языка C++, так и из-за того, что компилятор был новым, и Microsoft создавала его с течением времени по мере развития Office.

из-за этой истории, MFC:

1. имеет довольно неуклюжий дизайн. Он начинался как легкая обертка вокруг Windows API, но рос. Есть куча маленьких "функций", которые нужно было изобрести, потому что компилятор и язык просто не поддерживали их. Не было шаблонов,они изобрели класс string, они изобрели классы list, они разработали свою собственную идентификацию типа времени выполнения и т. д.
2. инкапсулирует 20 лет Office и Windows evolution, которая включает в себя целую нагрузку дерьма из вещей, которые вы, вероятно, никогда не будете использовать: один и несколько интерфейсов документов, DDE, COM, COM+, DCOM, связывание документов и встраивание (так что вы можете встраивать документ word в свое приложение, если хотите), элементы управления ActiveX (эволюция встраивания объектов для интернета!), Структурированное хранение документов, сериализация и управление версиями, автоматизация (с ранних лет VBA) и, конечно же, MVC. Последние версии поддерживают стыковку окон в стиле Visual Studio и ленту Office. В основном каждая технология из Редмонда через 20 лет где-то там. Он просто огромный!
3. имеет тонну маленьких gotchas, ошибок, обходных путей, предположений, поддержки вещей, которые все еще там, что вы никогда не будете использовать, и они вызывают проблемы. Вы должны быть хорошо знакомы с реализацией многих классов и тем, как они взаимодействуют, чтобы использовать его в проекте приличного размера. Распространено погружение в исходный код MFC во время отладки. Нахождение 15-летней технической заметки на некотором указателе, являющемся нулевым, вызывает авария все еще происходит. Предположения об инициализации древнего документа, встраивающего материал, могут повлиять на ваше приложение странным образом. В MFC нет такой вещи, как абстракция, вам нужно ежедневно работать с ее причудами и внутренними особенностями, она ничего не скрывает. И не заставляй меня начинать с классного мастера.

ATL был изобретен по мере развития языка C++, и появились шаблоны. ATL была демонстрацией того, как использовать шаблоны, чтобы избежать проблем во время выполнения MFC библиотека:

1. карты сообщений: поскольку они основаны на шаблонах, типы проверяются, и если вы испортите функцию bound, она не будет построена. В карты сообщений MFC макроэкономической основе, и связаны. Это может привести к странным ошибкам, сообщению, направленному в неправильное окно, сбою, если у вас неправильно определена функция или макрос, или просто не работает, потому что что-то не подключено правильно. Гораздо труднее отлаживать, и легче сломать без замечающий.
2. COM / Automation: подобно картам сообщений, COM изначально был привязан к времени выполнения с помощью макросов, требуя много ошибок и вызывая нечетные проблемы. ATL сделал его шаблоном, привязанным ко времени компиляции, и намного, намного проще иметь дело.

[Edit Embellishment: во время создания ATL техническая дорожная карта Microsoft была в основном сосредоточена на "управлении документами". Apple убивала их в настольном издательском бизнесе. Документ Office ' Увязка и внедрение "было одним из основных компонентов повышения" управления документацией " функции офиса, чтобы конкурировать в этом пространстве. COM была основной технологией, изобретенной для интеграции приложений, и API внедрения документов были основаны на COM. MFC было трудно использовать для этого случая использования. ATL было хорошим решением, чтобы сделать эту конкретную технологию проще для 3-й стороны реализовать COM и использовать функции встраивания документов.]

эти небольшие улучшения делают ATL чрезвычайно легче дело с простым приложением, которое не нуждается во всех офисных, как функции MFC. Что-то с простым пользовательским интерфейсом и некоторой автоматизацией Office. Это маленький, это быстро, это время компиляции, экономя много времени и головной боли. MFC имеет огромную библиотеку классов, которые могут быть неуклюжими и трудными для работы.

к сожалению, ATL застопорился. У него были обертки для поддержки Windows API и COM, а затем он никогда не выходил за рамки этого. Когда паутина взлетела, все это все было забыто, как старые новости.

[Edit Embellishment: Microsoft поняла, что эта "интернет-вещь" будет большой. Их техническая дорожная карта резко изменилась, чтобы сосредоточиться на Internet Explorer, Windows Server, IIS, ASP, SQL Server, COM/DCOM в распределенном сервере транзакций. Таким образом, связывание и внедрение документов больше не было приоритетным.]

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

в конечном итоге, какой из них использовать-это просто вопрос предпочтений. Большинство функций, которые вам нужны, находятся в базовом API ОС, который вы можете вызвать непосредственно из любой библиотеки, если в библиотеке нет подходящей оболочки.

только мои 2 цента, основанные на использовании MFC в течение многих лет,и я использую его ежедневно. Я баловался ATL когда он был впервые выпущен на нескольких проектах в течение пары лет. В те дни это был глоток свежего воздуха, но никогда никуда не уходил. А потом появилась паутина, и я забыл о ней.

Edit: этот ответ имеет удивительную долговечность. Поскольку он продолжает появляться на моей странице переполнения стека, я подумал, что добавлю некоторые украшения к первоначальному ответу, который, как я думал, отсутствовал.