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

Предполагая, что я только, используя их для "нормальных" графических программ (нет COM, нет ActiveX, ничего необычного), в чем принципиальное отличие, которое я буду видеть между ATL и MFC, чтобы помочь мне понять какой из них использовать?

Я сделал несколько поисков в Интернете, но в конечном итоге ни один из ответов не ответил на мой вопрос:

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

    • "ATL - это быстрый и простой способ создать COM-компонент на С++ и поддерживать небольшой размер. Используйте ATL для создания элемента управления, если вам не нужны все встроенные функции, которые MFC автоматически обеспечивает".

      Не отвечает на мой вопрос, потому что:

      • Я не работаю с COM.

      • Означает ли это, что MFC не работает быстро? Почему/как?

    • "MFC позволяет создавать полные приложения, элементы управления ActiveX и активные документы. Если вы уже создали элемент управления с MFC, вы можете продолжить разработку в MFC. При создании нового элемента управления рассмотрите возможность использования ATL если вам не нужны все встроенные функции MFC."

      Также не отвечает на мой вопрос, потому что:

      • Я даже не знаю, что такое ActiveX.

      • Похоже, Microsoft не поощряет использование MFC, но я не могу понять, почему.

      • Что такое MFC "встроенная функциональность", которую ATL не предоставляет?

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

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

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

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

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

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

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

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

ОТВЕТЫ

Ответ 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, когда он был выпущен на несколько проектов на пару лет. В те дни это был глоток свежего воздуха, но он никогда никуда не уходил. И затем появилась паутина, и я все это забыл.

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

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

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

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