MS Press -深入探索ATL技术详解

需积分: 10 26 浏览量更新于2024-07-24 收藏 1.06MB PDF 举报

"Inside ATL.pdf" 是一本由MS Press出版的关于Active Template Library (ATL) 的技术书籍，由George Shepherd和Brad King合著。这本书深入介绍了ATL的相关知识，适用于那些想要理解和开发使用ATL的软件工程师。 ATL是微软提供的一种C++库，它是为了简化COM（Component Object Model）组件的开发而设计的。COM是微软的一种二进制标准，允许不同进程间的对象交互，是Windows平台上构建组件和对象的核心技术。ATL通过模板和宏的使用，极大地减少了编写COM接口、工厂类和事件处理代码的工作量。书中内容可能涵盖了以下几个方面： 1. COM基础：解释了COM的基本概念，包括COM对象、接口、IUnknown接口、查询接口（QueryInterface）以及COM对象的生命周期管理。 2. ATL架构：介绍了ATL的核心类，如CComObjectRoot、CComPtr等，以及它们在实现COM对象中的作用。 3. ATL宏和模板：详细解析了ATL提供的各种宏和模板，如DECLARE_PROTECT_FINAL_CONSTRUCT、DECLARE_NOT_AGGREGATABLE等，以及如何利用它们快速创建COM组件。 4. ATL COM服务器：探讨了如何使用ATL创建本地和远程COM服务器，包括控制台应用程序、服务和Internet Explorer插件等。 5. ATL COM客户端：讲解了如何使用ATL来消费COM组件，包括动态和静态链接到COM服务器。 6. ATL与MFC集成：讨论了ATL与Microsoft Foundation Class (MFC) 库的协同工作，以及何时选择使用ATL而不是MFC。 7. ATL COM+支持：如果书中包含这部分，会介绍如何利用ATL构建COM+服务，包括事务、安全性、自动调度等特性。 8. ATL与OLEDB/OLE Automation：可能会讲解如何使用ATL来创建和使用数据访问对象，以及与自动化对象的交互。 9. 案例研究和最佳实践：提供了实际示例，帮助读者理解ATL在实际项目中的应用，以及开发高效、健壮COM组件的最佳实践。书中的索引部分会方便读者查找特定主题或技术，而版权信息则表明此书内容受法律保护，未经许可不得复制或传播。此外，该书还可能在全球范围内发行，适应不同地区的读者需求。 "Inside ATL" 是一本面向高级C++程序员的深入指南，对于想要掌握ATL并提高COM开发效率的开发者来说，是一本非常有价值的参考资料。

To attach the interface to some working C++ code, just derive the spelling-checker class from

SpellCheckerInterface like this:

// checker.h

#include "checkeri.h"

class CSpellChecker : public SpellCheckerInterface {

static int m_nRefCount; // How many others are using this?

LPTEXTBLOB m_lpText; // LPTEXTBLOB is defined elsewhere.

public:

CSpellChecker(LPTEXTBLOB lpText) {

// Initialize.

}

virtual ~CSpellChecker() {

// Tear down.

}

void CheckIt() {

// Do what it takes.

}

};

CSpellChecker is the concrete class that actually implements the spelling-checker functionality. The only

difference between this class and the original CSpellChecker definition is that CSpellChecker now inherits

from SpellCheckerInterface. This inheritance adds SpellCheckerInterface's functions to CSpellChecker and

promises the compiler an implementation of CheckIt.

Construction and destruction We need to attend to one last detail: constructing and destroying the class.

Consider again what we're trying to do: we're trying to move all the C++-specific details to the DLL side of

the client/DLL boundary so that the client only needs to worry about accessing the pure functionality. C++

object construction and destruction both depend on compiler-specific C++ class information. For example, the

new operator has to know how to call the object's constructor, which implies that the new operator must have

knowledge about name mangling (a potential problem when going beyond DLL boundaries). In addition, the

constructor has to know the address of the object's vtable so that it can put that address in the object's vpointer

(an operation that requires class layout knowledge). As for the destructor, the name-mangling problem rears

its ugly head again. So we still need to come up with some substitutes for the new operator and the delete

operator and somehow manage the construction and destruction of objects.

What we really need to do is to move object construction and destruction behind the DLL wall so that all the

compiler-dependent stuff stays in one place. The obvious way to handle object construction is to export a

function from the DLL. For example, here's a bit of code that would work well as a constructor for the

spelling checker. Notice that what the client receives is not the CSpellChecker object itself but, rather, a

pointer to the SpellCheckerInterface.

#include "checkeri.h"

#include "checker.h"

SpellCheckerInterface* ConstructSpellChecker(LPTEXTBLOB lpText) {

return (SpellCheckerInterface*)

new CSpellChecker(LPTEXTBLOB lpText);

}

The DLL exports this function. Clients can acquire a pointer to this function by calling the standard Windows

API functions LoadLibrary and GetProcAddress. Once a client gets this function pointer, the client can call

the function whenever it requires the spelling-checker functionality.

Before moving on, you need to understand an interesting bit of C++ chicanery that's going on here. Notice

how the function casts the result of the new operator (which is a CSpellChecker pointer) to a pointer to the

abstract base class (SpellCheckerInterface*). This cast might look a bit odd, but it's done for a reason. One

not-so-well-known fact about C++ is that casting an object pointer to one of its pure abstract base class

derivatives yields a pointer to that pure abstract base class, which is just a function table. Just what we want!

16 The Atoms of COM

Using the spelling-checker object Using the spelling checker requires going to the Win32 API and explicitly

loading the DLL and calling the constructor function. Here's how a client might acquire and use the

SpellCheckerInterface:

#include "checkeri.h"

typedef SpellCheckerInterface*

(WINAPI* LPSPELLCHECKERCTOR)(LPTEXTBLOB);

void UseSpellChecker(LPTEXTBLOB lpText) {

SpellCheckerInterface* pSpellChecker = NULL;

LPSPELLCHECKERCTOR lpSpellCheckCtor = NULL;

HINSTANCE hInstance;

HInstance = LoadLibrary("c:\\spellingchecker.dll");

lpSpellCheckCtor =

GetProcAddress(hInstance, "ConstructSpellChecker");

pSpellChecker = lpSpellCheckCtor(lpText);

pSpellChecker->CheckIt();

}

This code doesn't venture beyond the realm of regular DLL coding techniques. UseSpellChecker first declares

a pointer to a SpellCheckerInterface object. (The compiler sees this object simply as a function table.) In

addition, UseSpellChecker declares a pointer to a function prototyped as the DLL's entry point used for

obtaining spelling-checker interfaces. UseSpellChecker calls the Windows API function GetProcAddress to

get the address of the DLL's ConstructSpellChecker function and then calls ConstructSpellChecker to get a

SpellCheckerInterface. Once UseSpellChecker has the interface, it can use the interface to check the spelling

of the block of text.

Destroying the spelling-checker object As you can see from the code on the preceding page, the

spelling-checker object is allocated but never freed. How do you handle object destruction in a case like this?

Destroying a C++ object isn't a simple prospect—it involves deallocating memory properly and calling the

object's destructor. Again, memory allocation and object construction policies aren't something we want to

share between client/DLL boundaries. We have to somehow ask the DLL to destroy the object. At first, it

seems as though we might be able to export a single destructor function (as an analogue to the constructor

function). However, that would be fairly inconvenient. A better way to handle the destruction is to add one

more member function to the interface so that the client can ask the object to delete itself when it's done using

the object. So the SpellCheckerInterface gets a new function named DeleteMe, as shown here:

// checkeri.h

class SpellCheckerInterface {

public:

virtual void DeleteMe() = 0;

virtual void CheckIt() = 0;

};

The implementation code looks like this:

void CSpellChecker::DeleteMe() {

delete this;

}

This code might look funny, but it's perfectly legal C++ syntax. Calling delete with this simply calls the

object's destructor and then deallocates any memory the object used in the normal C++ way. The important

point to realize is that this activity is happening on the DLL side of the client/DLL boundary, thereby

decoupling the DLL from the client.

The Atoms of COM 17

Now let's finish the example. Here's how a client might use and destroy your spelling-checker object:

#include "checkeri.h"

void UseSpellChecker(LPTEXTBLOB lpText) {

/* Use the exported function */

/* to construct the object. */

pSpellChecker->CheckIt();

pSpellChecker->DeleteMe();

}

Immutable interfaces At this point, you know that an interface is just a collection of function signatures.

(C++ represents these interfaces as abstract base classes.) You also know that the only way for client code to

talk to an object is through the interface. Let's add one more ingredient—the idea that interfaces should

remain immutable. Once you've decided which functions to include in the spelling-checker interface and

clients start coding to the interface, the spelling-checker interface should never change. Of course, this

immutability means that if a client can get a spelling-checker interface pointer, the client can count on having

a well-known way to talk to the spelling-checker object.

Now you're probably thinking back and trying to recall the last project you worked on whose programmatic

interface didn't change eventually. You probably can't think of one. The notion of holding the interface

constant is all well and good: an ideal we should all aim for. But hey, we're in the real world, and software

changes. What should we do when we need to add functionality or change an interface to a class?

The answer is to create a completely new interface with a new name. Imagine that you want to add a new

function to your spelling-checker interface. To avoid breaking new clients by changing the existing interface,

you simply need to create a new interface. For example, let's say you want to add a function to get synonyms

for a specific word:

class SpellCheckerInterface2 : SpellCheckerInterface {

public:

// DeleteMe and CheckIt come from SpellCheckerInterface.

virtual char* GetSynonyms(char* szWord) = 0;

};

To implement this interface, you simply apply SpellCheckerInterface2 to the concrete class:

// checker.h

#include "checkeri.h"

class CSpellChecker : public SpellCheckerInterface2 {

static int m_nRefCount; // How many others are using this?

LPTEXTBLOB m_lpText; // LPTEXTBLOB is defined elsewhere.

public:

CSpellChecker(LPTEXTBLOB lpText) {

// Initialize.

}

virtual ~CSpellChecker() {

// Tear down.

}

void CheckIt() {

// Do what it takes.

}

void DeleteMe() {

delete this;

}

char* GetSynonyms(char* szWord) {

// Generate synonyms.

}

};

18 The Atoms of COM

The problem is that you've now enabled two ways to talk to the spelling-checker class: through the

SpellCheckerInterface base class and through the SpellCheckerInterface2 interface. To solve this problem,

should you just add another entry point into the DLL (perhaps a function named ConstructSpellChecker2) to

get the second version of the interface?

The way to fix this problem is to provide a well-known way to get new interfaces from an existing interface.

For example, imagine that SpellCheckerInterface and SpellCheckerInterface2 look like this:

class SpellCheckerInterface {

public:

virtual void* GetInterface(char* szInterfaceName) = 0;

virtual void DeleteMe() = 0;

virtual void CheckIt() = 0;

};

class SpellCheckerInterface2 : SpellCheckerInterface {

public:

// GetInterface, DeleteMe, and CheckIt

// come from SpellCheckerInterface.

char* GetSynonyms(char* szWord);

};

Once the client gets a SpellCheckerInterface, the client has a way of navigating to a second interface on the

object by calling GetInterface. For example, here's how some client code might use GetInterface:

void UseSpellChecker(SpellCheckerInterface* pSpellChecker) {

pSpellChecker->CheckIt();

SpellCheckerInterface2* pSpellChecker2;

pSpellChecker2 =

pSpellChecker->GetInterface("SpellCheckerInterface2");

if (pSpellChecker2) {

char* szSynonyms[256];

pSpellChecker2->GetSynonyms("component");

}

};

When you think about it, this is a pretty good solution for the versioning problem we encountered earlier.

Because SpellCheckerInterface never changes, clients can always count on certain function signatures in the

interface. Older clients don't break. If you decide to add new functionality to the spelling-checker object, you

just create a new interface. The GetInterface function (always available at the top of the interfaces) provides a

way for you to acquire more interfaces as necessary.

Here's how you would implement the new version of the object:

// checker.h

#include "checkeri.h"

class CSpellChecker : public SpellCheckerInterface2 {

static int m_nRefCount; // How many others are using this?

LPTEXTBLOB m_lpText; // LPTEXTBLOB is defined elsewhere.

public:

CSpellChecker(LPTEXTBLOB lpText) {

// Initialize.

}

virtual ~CSpellChecker() {

// Tear down.

}

void* GetInterface(char* pszInterfaceName) {

if (stricmp(pszInterfaceName, "SpellCheckerInterface") {

return static_cast<SpellCheckerInterface*>(this);

} else if (stricmp(pszInterfaceName,

"SpellCheckerInterface2") {

The Atoms of COM 19

return static_cast<SpellCheckerInterface2*>(this);

} else {

return 0;

}

void CheckIt() {

// Do what it takes.

}

char* GetSynonyms(char* szWord) {

// Generate synonyms.

}

};

The only difference in this implementation is the addition of the GetInterface function. Notice how this

function is implemented. GetInterface examines the string passed in by the client. If the object implements the

interface that the client requested, the object performs a static cast on its own this pointer. This code looks

kind of funny, but it's perfectly legal. By casting the pointer to a concrete class to one of its base classes, the

C++ compiler shears into the object and retrieves that object's vptr (which just so happens to be a vtable

representing the interface functions).

Orthogonal interfaces Although at times you might want to extend an interface by adding or changing

functions, at other times you need to add completely new independent interfaces to your class. For example,

imagine you want to add an interface that persists the most frequently used words into a file. You might write

an interface that looks like this:

class PersistMFUInterface {

public:

virtual void* GetInterface(char* szInterfaceName) = 0;

virtual void DeleteMe() = 0;

virtual void PersistMFUWords(char* pszFileName) = 0;

};

Adding a new interface to an implementation is simply a matter of adding the abstract base class to the

inheritance list and modifying GetInterface to work properly, like so:

// checker.h

#include "checkeri.h"

class CSpellChecker : public SpellCheckerInterface2,

public PersistMFUInterface {

static int m_nRefCount; // How many others are using this?

LPTEXTBLOB m_lpText; // LPTEXTBLOB is defined elsewhere.

public:

CSpellChecker(LPTEXTBLOB lpText) {

// Initialize.

}

virtual ~CSpellChecker() {

// Tear down.

}

void* GetInterface(char* pszInterfaceName) {

if (stricmp(pszInterfaceName, "SpellCheckerInterface") {

return static_cast<SpellCheckerInterface*>(this);

} else if (stricmp(pszInterfaceName,

"SpellCheckerInterface2") {

return static_cast<SpellCheckerInterface2*>(this);

} else if (stricmp(pszInterfaceName, "PersistMFUInterface") {

return static_cast<PersistMFUInterface*>(this);

} else {

return 0;

}

void CheckIt() {

// Do what it takes.

20 The Atoms of COM

剩余287页未读，继续阅读

skjeong3

粉丝: 0
资源: 3

MS Press -深入探索ATL技术详解

ATL开发指南（第二版）PDF（带目录）+源码.rar

深入解析ATL(第2版)PDF 高清中文版

Inside ATL

Inside ATL.rar

Microsoft ATL\MS Press - Inside ATL.chm

深入解析ATL.pdf

深入解析ATL1.pdf

ATL.rar_ATL

Inside ATL 深入ATL编程.chm（英文版）

ATL.chm.zip_ATL_ATL WTL_ATL chm_atl c_atl c++

最新资源