Что такое atl visual studio

Обновлено: 08.01.2025

Знакомимся с мастером

Ваше знакомство с библиотекой ATL начнется с нового инструмента - мастера ATL COM AppWizard. Мы займемс подготовкой простого COM-объекта с двойным интерфейсом, организованного в виде DLL-модуля. Для начала сформируем рабочую область нового проекта в окне Developer Studio и выберем для него тип ATL COM AppWizard. (В нашем примере мы присвоили проекту им ATLTEST.) На экране появляется диалоговое окно, в котором можно задать исходные параметры для данного проекта.

Как вы можете убедиться, представленный в мастере выбор параметров для вашего проекта создани COM-объекта весьма обширен. Здесь в вашем распоряжении самые разные варианты, однако в данном случае, по-видимому, нам подойдут указанные параметры. Позднее мы обсудим вопрос о том, как в соответствии с вашими требованиями выбираются другие параметры. Однако сейчас давайте остановимся на данном варианте.

Теперь у нас есть возможность заменить имена, сформированные мастером. И снова мы предпочли предложенные по умолчанию, после чего мастер произвел на свет проект в виде каркаса нашего COM-объекта.

Получив необходимый для нашей ATL-программы минимум, посмотрим, что за файлы подготовил нам мастер.

Функции COM-объекта

В файле Atltest.cpp содержатся основные служебные функции COM-объекта, организованного как DLL-модуль. К ним относятся четыре экспортируемые функции, которые должны быть у любого такого объекта. Две из них - DllGetClassObject и DllCanUnloadNow - это обязательные функции. Именно через эти функции лежит путь к созданию средствами COM-библиотек новых COM-объектов, входящих в состав вашего DLL модуля, а также уточняетс возможность выгрузки данного модуля из памяти. Две другие функции - DllRegisterServer и DllUnregisterServer - необязательные. Однако они значительно обегчат вам жизнь с их помощью записываютс и удаляются сведения об этом DLL-модуле в системном реестре Windows, что избавит вас от необходимости подготовки отдельных REG-файлов для регистрации данного COM сервера. Мало вероятно, что когда-нибудь вам придется что-то менять в Atltest.cpp.

Описание COM-объекта в IDL-файле

Файл Atltest.IDL содержит описания вашего COM-объекта и его интерфейсов, составленные на языке Interface Definition Language (IDL). По мере того как вы добавляете, удаляете или вносите изменения в описания интерфейсов данного COM-объекта, обновляетс хранящаяся в нем информация. Перед вами - фрагмент из файла Atltest.IDL:

// После обработки файла компилятором MIDL // будут созданы библиотека типов // (файл Atltest.tlb) и объектный // код для организации межпроцессной связи. [ object, uuid(7D785DE3-07С0-11D0-896С-444553540000), dual, helpstring("Интерфейс IAtltest1"), pointer_default(unique) ] interface IAtltest1 : IDispatch < import "oaidl.idl"; HRESULT Bar( [in] BSTR s); // Пример рабочей функции >;

Как можно заметить, здесь имеется идентификатор (IID) двойного интерфейса вашего COM-объекта. Я поместил в этот фрагмент и функцию Bar, чтобы показать, как выглядит типичный прототип рабочей функции на языке IDL. Он мало отличается от подобных примеров на языке Си++; разница лишь в том, что здесь есть директива [in], наличие которой означает, что компилятор MIDL должен подготовить подходящий объектный код дл организации межпроцессного обмена, т. е. модуля, обеспечивающего возможность обращений к интерфейсам из других процесов.

В соответствии с выбранными вами из представленных мастером COM AppWizard исходными параметрами в результате обращения ATL к компилятору MIDL (Microsoft IDL Compiler) будет получен ряд выходных файлов. С помощью этого компилятора можно создать файл двоичной библиотеки типов с описанием всех COM-объектов вашего DLL модуля. В таком файле возможны сотни различных групп размеров, для установки которых в файле Atltest.IDL задаются директивы.

Существуют различные способы применения созданной вами библиотеки типов. Например, любой разработчик может обратиться к ней с помощью программы OLE2VIEW (имеющейся также в Win32 SDK), чтобы уточнить, какими средствами обладает данный COM-объект. Либо, воспользовавшись средствами Visual Basic, можно просмотреть эту библиотеку для проверки типов некоторой VB-программы и еще до реального вызова COM-объекта проверить соответствие имен его функций и типов их параметров.

Если из предложенных мастером ATL COM AppWizard вы выбрали тип интерфейса Custom (индивидуальный), компилятор MIDL кроме уже упомянутых подготовит и следующие файлы с исходными текстами на языке Cи: Atltest_i.c, Atltest_p.c, Atltest1.h и dlldata.c. Дл их компиляции необходим файл ATLTEST1PS.MAK, сформированный мастером. Эти файлы содержат специальные программы, которые обеспечивают возможность доступа к интерфейсам вашего COM-объекта из программ в других процессах Win32. Для COM-объектов, организованных в виде DLL модулей, подобных программ не требуется, поскольку Windows автоматически отображает данный DLL-модуль в адресное пространство процесса той программы, которая обращается к функциям ваших COM-объектов. Если же вы оформили COM-объект как EXE-файл, придется скомпилировать подготовленные компилятором MIDL файлы, с тем чтобы образовалс объектный код для межпроцессного обмена. Дело в том, что для COM-объекта, облеченного в форму EXE-файла, гарантировано выделение отдельного процесса Win32. Поэтому, для того чтобы был возможен доступ к их интерфейсам из программ в других процессах, потребуетс соответствующий код.

Описание интерфейсов и функций

В файле Atltest1.h хранятся описания интерфейсов COM-объекта и принадлежащих им функций. При внесении в описания этих интерфейсов дополнений, удалений или исправлений нужно вручную отредактировать данный файл, а также Atltest.IDL.

Взглянув на следующий пример, вы можете увидеть значительное отличие в том, как обращаются с COM-объектами ATL и MFC:

class Ctltest1 : public CComDualImpl<IAtltest1, &IID_IAtltest1, &LIBID_ATLTESTLib>, public ISupportErrorInfo, public CComObjectRoot, public CComCoClass<CAtltest1, &CLSID_CAtltest1>

Как можно заметить, в ATL для реализации нескольких интерфейсов одного COM-объекта используется механизм множественного наследования, имеющийся в Си++. Такой подход проще и гораздо элегантнее, чем предусмотренное в MFC применение метода вложенных классов, когда речь идет о нескольких интерфейсах. А поскольку нет вложенных классов, значит. нет и потребности в макроконструкции METHOD_PROLOGUE для создани эквивалента указателю this.

Обратите внимание также на использование большого числа шаблонов при генерации программ обработчиков расширенного и IUnknown-интерфейсов вашего COM-объекта. В собственно объект войдут лишь модули, необходимые дл обработки выбранного вами в мастере COM AppWizard типа интерфейса. При компиляции никаких дополнительных модулей из внешних библиотек добавляться не будет, что способствует более строгому контролю над размером файла полученной программы.

Далее описание класса вы дополняете определениями принадлежащих функций интерфейса вашего COM-объекта:

// IAtltest1 public: STDMETHOD(Bar)(BSTR s); >;

Придется внести изменения и в соответствующий раздел файла Atetest 1.h, с тем чтобы в него вошли эти описания функций. В нашем примере я воспользовалс макрокомандой STDMETHOD, чтобы объявить интерфейсную функцию Bar с единственным параметром типа BSTR (BASIC-строка). Аналогичным образом определяются и другие принадлежащие функции и их параметры вне зависимости от того, какого типа интерфейс дл COM-объекта вы хотите реализовать - заказной или расширенный.

Реализация методов

Файл Atltest1.cpp содержит программы, реализующие методы вашего COM-объекта. Мастер COM AppWizard уже подготовил принимаемые по умолчанию функции интерфейса ISupportErrorInfo.

При составлении программ для интерфейсных методов вашего COM-объекта, как правило, используетс макрокоманда STDMETHODIMP. Это показано на следующем примере:

STDMETHODIMP CAtltest1::Bar( BSTR s )

Любой COM-объект должен передавать в вызывающую программу некоторый код стандартной ошибки HRESULT. Если передается S_OK, значит, ошибок нет. При возникновении ошибки return-значениям станет один из кодов стандартных ошибок, описания которых имеются в файле winerror.h, входящем в состав Win32 SDK, вы найдете его в каталоге \msdev\include.

Описание интерфейсов на языке C++

При создании COM-объекта компилятор MIDL автоматически подготовит файл Atltest.h, который содержит описание на языке Cи++ всех COM-интерфейсов вашего объекта. Так выглядит составленное компилятором MIDL-определение COM-интерфейса ISimpleObj:

При внесении в описание интерфейса вашего COM-объекта изменений нет необходимости редактировать этот файл вручную. Обновить следует файлы Atltest.IDL и Atltest1.h. Следует отметить очень важный момент: не забывайте приводить в соответствие содержимое этих файлов, поскольку именно в них задается описание интерфейса вашего COM-объекта.

Параметры GUID в стиле Си++

В файле Atltest_i.c представлены все идентификаторы GUID, в которых нуждается ваша программа. Их формирует мастер COM AppWizard с помощью функции CoCreateGuid, предусмотренной в интерфейсе COM API. Однако все эти GUID-значения сохраняются мастером в файле Atltest.IDL как различные параметры. К счастью, компилятор MIDL просматривает IDL файл и формирует идентификаторы GUID в стиле Си++:

Выбор параметров

Теперь посмотрим, какие варианты параметров предлагаются мастером и какими соображениями руководствоваться при их выборе.

Наверное, самое главное - это решить, в какую форму облечь COM-объект - DLL-модуля или EXE-файла. Это решение будет иметь далеко идущие последствия - как с точки зрения быстродействия вашего COM-объекта, так и надежности его работы.

Короче говоря, если COM-объект организован в виде DLL-модуля, а не EXE-файла, операции обращений к нему выполняются значительно быстрее - на несколько порядков. Однако не следует забывать, что форма организации COM-объекта влияет лишь на скорость выполнения обращений к нему, а не на быстродействие программы самого COM-объекта. Поэтому оформлять COM-объект в виде DLL-модуля целесообразно в том случае, если предполагается, что он достаточно часто будет вызываться клиентскими программами. Другими словами, имеет смысл прибегнуть к такой форме, если операция вызова COM-объекта занимает значительную долю суммарного времени, необходимого для обращения к одному из его методов.

Если же ваше основное требование к COM-объекту - надежность, вполне разумно было бы организовать его как EXE-файл. Дело в том, что COM-объект, оформленный в виде EXE-файла, выполняется в своем собственном, защищенном адресном пространстве процесса Win32. Если же данный объект облечен в форму DLL-модуля, он будет выполняться в адресном пространстве процесса вызвавшей его программы. Для EXE-формы COM-объекта возможен доступ лишь к тем областям памяти, которые находятся в пределах адресного пространства его собственного процесса (для Windows 95 сказанное верно лишь частично, для Windows NT - абсолютно). Поэтому маловероятно, что имеющаяся в программе COM-объекта ошибка приведет к сбою обратившейся к нему программы-клиента.

Наконец, если ваш COM-объект должен управлять некоторым совместно используемым ресурсом, имеющимся в памяти, тогда вопрос о его форме вы решаете сами. COM-объект в виде EXE-файла свободно распоряжаетс памятью в рамках адресного пространства собственного процесса. А память, выделяемая COM-объектом в виде DLL-модуля, ограничена рамками пространства, в котором выполняется процесс вызвавшей его программы. Для того чтобы некоторый разделяемый ресурс в памяти стал доступен сразу нескольким программам-клиентам, DLL-модулю придется запросить блок памяти из глобального хипа. А реализация подобных возможностей потребует некоторых дополнительных модулей, не говор уже о том, что разарботчику придется разбираться в сложностях размещения файлов в памяти. В данном случае вы должны решить, что для вас важнее - быстродействие или надежность.

Выбор типа интерфейса

В ATL вы можете выбрать один из двух типов COM-интерфейса для своего объекта - индивидуальный (Custom) или двойной (Dual).

Индивидуальный COM-интерфейс создается как производный от IUnknown. Интерфейс такого типа отличается наивысшим быстродействием, причем в качестве аргументов для его функций пригодны любые типы данных. Если к COM-интерфейсу будут обращатьс программы-клиенты, выполняющиеся в адресных пространствах других процессов, компилятор MIDL автоматически сформирует модули, обеспечивающие межпроцессную связь. Благодаря применению ATL и MIDL весь процесс создания индивидуальных интерфейсов сводится просто к внесению элементов в IDL-файл и в файл заголовков нового COM-объекта.

Второй вариант COM-интерфейса - двойной интерфейс, который порождается из IDispatch, а не IUnknown (хот интерфейс IDispatch - производный от IUnknown). В этом случае вы получаете наилучшее решение двух проблем. Во-первых, к нему могут обращаться разнообразные прикладные программы (например, составленные на Visual Basic и не обладающие средствами для работы с указателями и механизмом наследования на уровне классов). Во-вторых, его быстродействие не отличаетс от аналогичного показателя индивидуального COM-интерфейса.

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

Что выбрать - ATL или MFC?

Решение вопроса о том, какой из инструментальных пакетов - ATL или MFC - выбрать, зависит главным образом от того, какого сорта COM-объект вы собираетесь создать. В узком смысле слова COM-объект - это любой объект с интерфейсом IUnknown. Если исходить из этого определения, любые серверы обработки документов с ActiveX-элементами и ActiveX-элементы на самом деле можно считать COM-объектами.

Если вы намерены заняться разработкой ActiveX-элементов, лучше избегать использования средств ATL. Реализовать полный перечень интерфейсов, необходимых для ActiveX-элементов, вам поможет MFC. Если же вы сочтете, что размер файлов, создаваемых средствами MFC, чрезмерно велик, тогда, может быть, вам попытаться добиться цели с помощью инструментов BaseCtl ActiveX, входящих в состав пакета ActiveX SDK. Примен эти средства, вы получите компактные ActiveX-элементы, избежав при этом непроизводительных излишеств, как в случае MFC.

Если ваша задача - разработка серверов обработки документов, содержащих ActiveX-элементы, и эти серверы будут работать в среде Web-браузера, например Internet Explorer 3.0, то не пытайтесь воспользоваться ATL. Только MFC - идеальный вариант для решени документо-ориентированных задач и выполнит основную часть рутинной работы.

Если же вы собираетесь создавать библиотеки объектно-ориентированных подпрограмм, предназначенных для использования многими программами, в этом случае непревзойденными считаются средства ATL. При обычной задаче формирования стандартной DLL или MFC Extension DLL (DLL-расширения библиотеки MFC) обратите внимание на простоту ее подготовки средствами ATL. В результате ваши объектно-ориентированные программы будут полностью разделяемыми, а также к вашим библиотекам смогут обращаться модули, составленные практически на любом языке программирования для Windows. Более того, эти программы-клиенты могут находиться на другом компьютере. С появлением библиотек распределенных COM-объектов Distributed COM фирмы Microsoft, предусмотренных в Windows NT 4.0, ваши COM-объекты становятся доступными по сети любой программе - причем без каких-бы то ни было изменений.

Библиотека активных шаблонов (ATL) - это набор классов C ++ на основе шаблонов, разработанный Microsoft и предназначенный для упрощения программирования объектов модели компонентных объектов (COM). Поддержка COM в Microsoft Visual C ++ позволяет разработчикам создавать различные COM-объекты, серверы OLE Automation и элементы управления ActiveX . ATL включает в себя мастер объектов, который быстро устанавливает первичную структуру объектов с минимумом ручного кодирования. На стороне клиента COM ATL предоставляет интеллектуальные указатели, которые имеют дело с подсчетом ссылок COM. Библиотека интенсивно использует любопытно повторяющийся шаблон шаблона .

СОДЕРЖАНИЕ

История

COM-объекты также могут быть созданы с помощью Microsoft Foundation Classes (MFC), но это приводит к большим двоичным файлам, требующим поддержки DLL . ATL, с другой стороны, является более легкой альтернативой в ситуациях, когда части графического пользовательского интерфейса MFC не требуются.

В ATL версии 7 (Visual Studio 2003), которая непосредственно пришла на смену версии 3 (Visual Studio 6.0), ряд классов MFC, таких как CString, были доступны в ATL или, точнее, перемещены на общий уровень ATLMFC, который используется обеими библиотеками. ATL версии 7 также представил атрибуты в C ++ в попытке предоставить что-то похожее на атрибуты CLI , однако они не принесли особого успеха и были недооценены в ATL версии 8 (Visual Studio 2005); различные мастера больше не генерируют их по умолчанию. Версия 7 также представила новые классы преобразования строк.

Начиная с Visual Studio 2013, код ATL в Visual C ++ 2013 является статическим, что исключает DLL.

Классы поддержки

ATL включает в себя множество классов RAII для упрощения управления типами COM. К наиболее часто используемым классам относятся:

CComPtr<T> универсальный смарт-указатель,
CComBSTR Обертка BSTR,
CComVariant Обертка VARIANT и
CComSafeArray<T> БЕЗОПАСНАЯ обертка.

Поддержка COM компилятора

Хотя формально Microsoft Visual C ++ не является частью ATL, он также включает дополнительные классы C ++ RAII для упрощения управления типами COM. Эти классы поддержки COM компилятора могут использоваться в качестве замены или в сочетании с ATL и включают в себя:

_com_ptr_t умный указатель, который украшает имя COM-интерфейса суффиксом "Ptr",
_bstr_t Обертка BSTR,
_variant_t Обертка VARIANT и
_com_error Обертка HRESULT.

Обратите внимание, что начиная с Visual Studio 2012 классы поддержки COM компилятора не включают оболочку SAFEARRAY.

Обзор архитектуры ATL Server

ATL Server связывает классы и функции, хранящиеся в DLL , используя теги в текстовых файлах. В результате этого запросы к IIS могут вызывать функции внутри библиотек и возвращать запрашивающему клиенту содержимое текстового файла вместе с результатами вызова функции. ATL Server использует ISAPI для реализации механизма вызова между текстовыми файлами, IIS и библиотеками DLL с использованием системы командных тегов, поддерживаемой технологией . NET . Простейшее программное решение ATL Server включает в себя следующие компоненты.

Библиотека DLL расширения ISAPI.
Библиотека DLL интернет-приложения или DLL поддержки запросов.
Файл ответа сервера (SRF).
Службы IIS.

При отправке запросов в IIS на ресурс , которым является источник ATL Server , IIS связывает вызов с библиотекой DLL расширения ISAPI . После получения этого запроса расширение ISAPI открывает и обрабатывает библиотеку DLL запрошенного веб-приложения или файл ответа сервера. Если запрошен файл ответа сервера, то вызывается тег замещения, обозначающий вызов функции из библиотеки DLL веб-приложения, и результаты работы вставляются в файл ответа сервера в месте расположения тега замещения. Комбинация результатов вызовов к DLL веб-приложения и содержимое файла ответа сервера возвращаются запрашивавшей стороне. Если DLL веб-приложения запрашивается напрямую, библиотека DLL расширения ISAPI выполняет соответствующий вызов (вызовы) и возвращает результаты в браузер .

На рисунке 4.1 приведен обзор архитектуры ATL Server .

Так как библиотека DLL расширения ISAPI может располагаться на несущем сервере не в корневом веб-каталоге, то IIS нужно знать, какие действия выполнять с файлом расширения ISAPI и файлами, связанными с библиотекой DLL расширения ISAPI (файлами ответа сервера и DLL веб-приложения). Чтобы сравнить программное решение для интернета, требующее текстовых файлов для обработки расширением ISAPI , мы будем использовать технологию ASP и противопоставим ее механизму IIS для связи файлов и расширения ISAPI . IIS известно, как обрабатывать файлы ASP , поскольку имена файлов, оканчивающиеся на . asp обрабатываются с помощью расширения ISAPI с именем ASP . DLL .

Код внутри ASP . DLL открывает связанный ASP - файл и интерпретирует код в тегах ASP . Веб-формы и веб-службы, работающие с файлами .aspx и .asmx , используют такой же механизм, только они применяют технологию . NET вместо ASP . DLL для интерпретации кода и тегов, содержащихся в соответствующих файлах.

ATL Server с помощью библиотек DLL расширения ISAPI интерпретирует код, включенный в теги файла ответа сервера, и вызовы функций, определенные тегами замещения в библиотеке DLL веб-приложения. При создании веб-приложения с использованием файлов ASP разработчик ни в коем случае не станет перекомпилировать ASP . DLL таким образом, чтобы она содержала только код для обработки функций ASP . ASP . DLL не изменяется от одного ASP -приложения к другому; по существу, именно за счет этого работает одна библиотека DLL расширения ISAPI . Имейте в виду, что ATL Server создает особый интерпретатор для строящегося программного решения, оптимизированный именно для этого решения. Он также является библиотекой DLL расширения ISAPI , которая входит в проект ATL Server . Разработчик имеет прекрасную возможность модифицировать ее в соответствии с требованиями конкретного приложения, а не использовать конфигурацию по умолчанию.

Ниже показано, как можно связать расширения имен файлов с расширениями ISAPI .

Откройте консоль MMC для IIS.
Щелкните на значке папки Web Site (Веб-узел) в дереве папок, чтобы развернуть список экземпляров веб-сервера на сервере, затем щелкните на экземпляре веб-сайта, который необходимо настроить, для отображения его содержимого.
Откройте окно свойств для любого веб-объекта или виртуального каталога и нажмите на кнопку Configuration (Настройка) во вкладке Home Directory (Домашний каталог) или Virtual Directory (Виртуальный каталог) соответственно. Откроется апплет Application Configuration (Настройка приложения) (см. рис. 4.2).
Свяжите файл и путь к нужной DLL-библиотеке расширения ISAPI на сайте. После этого IIS необходимо перезапустить.

Рис. 4.2. Окно настройки приложения предназначено для связывания файлов с расширениями

Ни одна из задействованных библиотек не является DLL -библиотекой модели компонентных объектов ( COM ), поэтому IIS и компоненты ATL Server для поиска нужных DLL -библиотек физически отыскивают их на узле по текущим файловым расположениям.

Многие из разработчиков знают, что расположение COM -объекта на узле определяется связыванием уникального идентификационного номера (CLSID) с путем к файлу DLL . Эта информация записывается в реестр Windows , и любое программное обеспечение , запрашивающее использование DLL -библиотеки COM - объекта, сможет работать с ней. Доступ к DLL с помощью ее физического нахождения и загрузки выглядит несколько устаревшим по сравнении с архитектурой, появившейся после технологии COM , но такое решение дает некоторые преимущества с точки зрения управления. Связи с файлами в IIS базируются на файловых расширениях. DLL -библиотека веб-приложения указывается посредством относительного пути. Перемещение файлов на другой сервер нарушает связи файлов IIS с DLL -библиотекой расширения ISAPI , но другие файлы перемещаются так, как если бы они являлись статическим содержимым, поскольку их расположение относительно друг друга контролируется.

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

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

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

Я не работать с COM.

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

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

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

Я даже не знаю, что такое ActiveX is в первую очередь.

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

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

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

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

"ATL & MFC несколько сложнее выбрать. [[не шучу!]] Я бы сослался вам!--91-- > страница MSDN для выбора, чтобы выбирать между ними."

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

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

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

что я пропустила?

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

короткий ответ: если вы не делаете ничего "причудливого", используйте 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 библиотека:

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

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

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

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

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

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

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

Читайте также: