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

Предполагая, что я использую их только для «обычных» программ с графическим интерфейсом (без 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, но я не могу понять почему.

    • Что именно является МФЦ «встроенные функции» , что ATL не дает?

  • В общем, это не отвечает на мой вопрос, потому что не объясняет недостатки и их причины.

потому что прямо или косвенно все похоже на предыдущую страницу:

• Как мне решить, использовать ли ATL, MFC, Win32 или CLR для нового проекта C ++?

  • «ATL и MFC несколько сложнее выбрать между ними. [[Без шуток!]] Я бы направил вас на страницу MSDN для выбора, чтобы сделать выбор между ними».

    Очевидно , это не ответ на мой вопрос. :)

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

• и т.п.

То, что я сейчас наблюдал (в течение последних двух дней, пытаясь изучить оба):

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

Но архитектурной разницы между ними, похоже, нет :

• Оба используют карты сообщений ( BEGIN_MSG_MAPпротив BEGIN_MESSAGE_MAP... большого дела)
• Оба оборачивают методы Win32 в классы
• Оба, похоже, имеют похожие классы CWndvs.CWindow

Но тогда, если нет реальной разницы, кроме аспекта времени компиляции и времени выполнения, тогда почему они оба существуют? Разве одного из них должно быть недостаточно?

Что мне здесь не хватает?

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

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

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

[Правка приукрашивания: я не работал в 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, но затем вырос. Есть куча маленьких «функций», которые пришлось изобрести, потому что компилятор и язык просто не поддерживали их. Не было шаблонов, они изобрели строковый класс, они изобрели классы списков, они разработали свою собственную идентификацию типа во время выполнения и т. Д.
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 техническая дорожная карта Microsoft была в основном сосредоточена на «управлении документами». Apple убивала их в настольном издательском бизнесе. «Связывание и встраивание документов» в Office было основным компонентом улучшения функций «Управление документами» в Office, чтобы они могли конкурировать в этой сфере. COM была основной технологией, изобретенной для интеграции приложений, а API встраивания документов были основаны на COM. MFC было сложно использовать для этого варианта использования. ATL был хорошим решением, упростившим эту конкретную технологию сторонним разработчикам для реализации COM и использования функций встраивания документов.]

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

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

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

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

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

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

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

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

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

Что это за «дополнительная функциональность», которую они все время упоминают? Оно мне нужно?

Если вы определите свои требования, возможно, будет легче ответить, если вы сможете избежать использования MFC. К сожалению, «ничего необычного» недостаточно. Более подробное описание того, какие функции вы собираетесь использовать, может оказаться более полезным (какие элементы управления, какие фреймворки / технологии / существующие библиотеки вы хотите использовать и т. Д.).

Но вот статья, в которой описаны некоторые функции MFC, которые напрямую не поддерживаются WTL / ATL.

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

ATL - это набор классов, предназначенный для упрощения реализации COM-объектов.

Вы можете использовать его без MFC. На моей работе мы используем ATL, чтобы предоставить вычислительному коду COM-интерфейсы. Здесь нет графического интерфейса пользователя, нам нужно иметь возможность вызывать этот вычислительный код, например, из. Excel VBA.

Посмотрите какое-нибудь руководство / учебное пособие по COM, чтобы увидеть, что в нем абстрагируется.

MFC - это просто набор классов-оболочек графического интерфейса пользователя для Win32 API. Взгляните на учебник по Win32 API, чтобы понять, что он абстрагирует.