Ответ 1
Я думаю, что ответ на ваш вопрос в основном исторический, если вы посмотрите на то, как две библиотеки возникли и эволюционировали во времени.
Короткий ответ: если вы ничего не делаете "причудливо", используйте ATL. Это отлично подходит для простых пользовательских интерфейсов с COM-броском.
Длинный ответ: MFC была построена в начале 90-х годов, чтобы опробовать новый язык под названием С++ и применить его к Windows. Это сделало Office как функции доступными сообществу разработчиков, когда ОС еще не имела их.
[Редактировать приукрашивание: я не работал в Microsoft, поэтому я не знаю, был ли Office когда-либо построен на MFC, но я думаю, что ответ отрицательный. В Win 3.1, Win 95, команда Office UI создала новые элементы управления, упаковывала их в библиотеки, а затем команды Windows и MFC включали обертки и API для этих элементов управления с распространяемыми DLL. Я бы предположил, что между этими командами было немного сотрудничества и обмена кодами. В конце концов эти элементы управления попадут в базовую операционную систему в пакеты обновления или следующую версию Windows. Этот шаблон продолжался с лентой Office, которая была добавлена в Windows в качестве дополнительного компонента после отправки Office и теперь является частью ОС Windows.]
В то время библиотека была довольно примитивной, поскольку из-за того, что язык С++ и новый компилятор были новыми, а Microsoft наращивала его со временем по мере развития Office.
Из-за этой истории MFC:
- Имеет довольно неуклюжий дизайн. Это началось как легкая обертка вокруг Windows API, но росло. Есть куча маленьких "функций", которые нужно было изобрести, потому что компилятор и язык просто не поддерживали их. Не было шаблонов, они придумали класс строк, изобрели классы классов, разработали собственную идентификацию типа времени выполнения и т.д.
- Инкапсулирует 20-летнюю эволюцию Office и Windows, которая включает в себя всю грубую загрузку материалов, которые вы, вероятно, никогда не будете использовать: интерфейсы с одним и несколькими документами, DDE, COM, COM +, DCOM, связывание и встраивание документов (чтобы вы могли встроить текстовый документ в вашем приложении, если вы этого захотите), элементы управления ActiveX (эволюция встраивания объектов для Интернета!), хранилище структурированных документов, сериализация и управление версиями, автоматизация (с ранних лет VBA) и, конечно же, MVC. В последних версиях поддерживается поддержка стыковки окон в стиле Visual Studio и лента Office. В принципе, каждая технология из Редмонда через 20 лет находится где-то там. Это просто ОГРОМНОЕ!
- Есть тонна маленьких ошибок, ошибок, обходных решений, предположений, поддержки вещей, которые все еще существуют, которые вы никогда не будете использовать, и они вызывают проблемы. Вы должны быть хорошо знакомы с реализацией многих классов и как они взаимодействуют, чтобы использовать его в проекте с достойным размером. Распространение исходного кода MFC во время отладки является обычным явлением. Поиск 15-летней технической заметки о том, что какой-то указатель имеет нулевое значение, вызывает крах. Предположения об инициализации материалов для встраивания древних документов могут повлиять на ваше приложение странными способами. В MFC нет такой вещи, как абстракция, вам нужно ежедневно работать с ней причудами и внутренностями, она ничего не скрывает. И не заставляйте меня начинать с мастера классов.
ATL был изобретен как язык С++, и появились шаблоны. ATL была демонстрацией использования шаблонов, чтобы избежать проблем времени исполнения библиотеки MFC:
- Карты сообщений. Поскольку они основаны на шаблонах, типы проверяются, и если вы испортили связанную функцию, она не строится. В MFC-сообщениях отображаются макросы и время выполнения. Это может привести к нечетным ошибкам, сообщению, направленному в неправильное окно, сбою, если у вас есть функция или макрос, определенный неправильно или просто не работает, потому что что-то не подключено правильно. Гораздо сложнее отлаживать, и проще сломать, не замечая.
- COM/Automation: как и в случае с картами сообщений, COM изначально выполнялся с использованием макросов, требуя много ошибок и вызывающих нечетные проблемы. ATL создала его на основе шаблона, скомпилировала временную привязку и многое, гораздо легче справиться.
[Edit Embellishment: В то время, когда был создан ATL, техническая дорожная карта Microsoft была в основном сосредоточена на "Document Management". Apple убивала их в настольном издательском бизнесе. "Связывание документов и их внедрение" было основным компонентом для улучшения функций "Управление документами" Office, чтобы конкурировать в этом пространстве. COM был основной технологией, изобретенной для интеграции приложений, а API Document Embedding основан на COM. MFC трудно использовать для этого случая использования. ATL было хорошим решением для упрощения этой конкретной технологии для сторонних разработчиков COM и использования функций вложения документов.]
Эти небольшие усовершенствования упрощают работу ATL в простом приложении, которое не нуждается во всех функциях офиса, таких как функции MFC. Что-то с простым пользовательским интерфейсом и некоторой автоматизацией Office. В нем мало, быстро, он компилирует время, экономя ваше время и головную боль. MFC имеет огромную библиотеку классов, которые могут быть неуклюжими и с трудом работать.
К сожалению, ATL застопорился. У него были обертки для API окон и поддержки COM, и тогда это никогда не выходило за рамки этого. Когда Web взлетел, все эти вещи были забыты как старые новости.
[Править Приукрашивание: Microsoft поняла, что эта "Интернет-вещь" будет большой. Их техническая дорожная карта резко изменилась, чтобы сосредоточиться на Internet Explorer, Windows Server, IIS, ASP, SQL Server, COM/DCOM на сервере распределенных транзакций. Таким образом, связывание и вложение документов больше не было высоким приоритетом.]
Огромный след MFC сделал невозможным их сброс, поэтому он все еще медленно развивается. Шаблоны были включены в библиотеку, а также другие улучшения языка и API. (Я не слышал о WTL, пока не увидел этот вопрос.:)
В конечном счете, тот, который нужно использовать, - это просто вопрос предпочтения. Большинство функций, которые вам нужны, находятся в базовом OS API, который вы можете вызывать непосредственно из любой библиотеки, если в библиотеке нет подходящей обертки.
Только мои 2 цента на основе использования MFC в течение многих лет, и я использую его сейчас ежедневно. Я баловался в ATL, когда он был выпущен на несколько проектов на пару лет. В те дни это был глоток свежего воздуха, но он никогда никуда не уходил. И затем появилась паутина, и я все это забыл.
Изменить: этот ответ имеет удивительное долголетие. Поскольку он продолжает появляться на моей странице, я думал, что добавлю некоторое украшение к оригинальному ответу, который, как мне казалось, не хватало.