C++博客-Programmer's Cookbook<梦在天涯>

《windows via C++》之windows线程同步

梦在天涯 — Tue, 29 Jul 2008 22:54:00 +0800

来自：梦在天涯C++博客(http://www.cppblog.com/mzty/)

一线程

1）如果你正在编写C/C++代码，决不应该调用CreateThread。相反，应该使用VisualC++运行期库函数_beginthreadex，退出也应该使用_endthreadex。如果不使用Microsoft的VisualC++编译器，你的编译器供应商有它自己的CreateThred替代函数。不管这个替代函数是什么，你都必须使用。

2）因为_beginthreadex和_endthreadex是CRT线程函数，所以必须注意编译选项runtimelibaray的选择，使用MT或MTD。

3) _beginthreadex函数的参数列表与CreateThread函数的参数列表是相同的，但是参数名和类型并不完全相同。这是因为Microsoft的C/C++运行期库的开发小组认为，C/C++运行期函数不应该对Windows数据类型有任何依赖。_beginthreadex函数也像CreateThread那样，返回新创建的线程的句柄。

4）下面是关于_beginthreadex的一些要点：

•每个线程均获得由C/C++运行期库的堆栈分配的自己的tiddata内存结构。（tiddata结构位于Mtdll.h文件中的VisualC++源代码中）。

•传递给_beginthreadex的线程函数的地址保存在tiddata内存块中。传递给该函数的参数也保存在该数据块中。

•_beginthreadex确实从内部调用CreateThread，因为这是操作系统了解如何创建新线程的唯一方法。

•当调用CreatetThread时，它被告知通过调用_threadstartex而不是pfnStartAddr来启动执行新线程。还有，传递给线程函数的参数是tiddata结构而不是pvParam的地址。

•如果一切顺利，就会像CreateThread那样返回线程句柄。如果任何操作失败了，便返回NULL。

5) _endthreadex的一些要点：

•C运行期库的_getptd函数内部调用操作系统的TlsGetValue函数，该函数负责检索调用线程的tiddata内存块的地址。

•然后该数据块被释放，而操作系统的ExitThread函数被调用，以便真正撤消该线程。当然，退出代码要正确地设置和传递。

6) 虽然也提供了简化版的的_beginthread和_endthread，但是可控制性太差，所以一般不使用。

6）线程handle因为是内核对象，所以需要在最后close handle。

7）C++主线程的终止，同时也会终止所有主线程创建的子线程，不管子线程有没有执行完毕。

8）如果某线程挂起，然后有调用WaitForSingleObject等待该线程，就会导致死锁。

二线程同步之Critical Sections

1）因为Critical Sections不是内核对象，所以只能用来同一进程内线程间的同步，不能用来多个不同进程间的线程的同步。

2）如果在Critical Sections中间突然程序crash或是exit而没有调用LeaveCriticalSection，则结果是该线程所对应的内核不能被释放，该线程成为死线程。

3）要比其他的内核对象的速度要快。

4）很好的封装：

class CritSect
{
public:
    friend class Lock;
    CritSect() { InitializeCriticalSection(&_critSection); }
    ~CritSect() { DeleteCriticalSection(&_critSection); }
private:
    void Acquire(){EnterCriticalSection(&_critSection);}
    void Release(){LeaveCriticalSection(&_critSection);}

CRITICAL_SECTION _critSection;
};

class Lock
{
public:
     Lock(CritSect& critSect):_critSect(critSect) {    _critSect.Acquire(); }
     ~Lock(){_critSect.Release();}
private:
    CritSect& _critSect;
};
调用：CritSect sect;Lock lock(sect);

三线程同步之Mutex

1）互斥对象（mutex）内核对象能够确保线程拥有对单个资源的互斥访问权。实际上互斥对象是因此而得名的。互斥对象包含一个使用数量，一个线程ID和一个递归计数器。
2）互斥对象的行为特性与关键代码段相同，但是互斥对象属于内核对象，而关键代码段则属于用户方式对象。这意味着互斥对象的运行速度比关键代码段要慢。但是这也意味着不同进程中的多个线程能够访问单个互斥对象，并且这意味着线程在等待访问资源时可以设定一个超时值。

3） ID用于标识系统中的哪个线程当前拥有互斥对象，递归计数器用于指明该线程拥有互斥对象的次数。

4）互斥对象有许多用途，属于最常用的内核对象之一。通常来说，它们用于保护由多个线程访问的内存块。如果多个线程要同时访问内存块，内存块中的数据就可能遭到破坏。互斥对象能够保证访问内存块的任何线程拥有对该内存块的独占访问权，这样就能够保证数据的完整性。

5）互斥对象的使用规则如下：

• 如果线程ID是0（这是个无效ID），互斥对象不被任何线程所拥有，并且发出该互斥对象的通知信号。

• 如果ID是个非0数字，那么一个线程就拥有互斥对象，并且不发出该互斥对象的通知信号。

• 与所有其他内核对象不同，互斥对象在操作系统中拥有特殊的代码，允许它们违反正常的规则。

四线程同步之Event

1）在所有的内核对象中，事件内核对象是个最基本的对象。它们包含一个使用计数（与所有内核对象一样），一个用于指明该事件是个自动重置的事件还是一个人工重置的事件的布尔值，另一个用于指明该事件处于已通知状态还是未通知状态的布尔值。

2）事件能够通知一个操作已经完成。有两种不同类型的事件对象。一种是人工重置的事件，另一种是自动重置的事件。当人工重置的事件得到通知时，等待该事件的所有线程均变为可调度线程。当一个自动重置的事件得到通知时，等待该事件的线程中只有一个线程变为可调度线程。

3）当一个线程执行初始化操作，然后通知另一个线程执行剩余的操作时，事件使用得最多。事件初始化为未通知状态，然后，当该线程完成它的初始化操作后，它就将事件设置为已通知状态。这时，一直在等待该事件的另一个线程发现该事件已经得到通知，因此它就变成可调度线程。

4）Microsoft为自动重置的事件定义了应该成功等待的副作用规则，即当线程成功地等待到该对象时，自动重置的事件就会自动重置到未通知状态。这就是自动重置的事件如何获得它们的名字的方法。通常没有必要为自动重置的事件调用ResetEvent函数，因为系统会自动对事件进行重置。但是，Microsoft没有为人工重置的事件定义成功等待的副作用，所以需要调用ResetEvent()。

五线程同步之其他

1）线程局部存储（TLS），同一进程中的所有线程共享相同的虚拟地址空间。不同的线程中的局部变量有不同的副本，但是static和globl变量是同一进程中的所有线程共享的。使用TLS技术可以为static和globl的变量，根据当前进程的线程数量创建一个array，每个线程可以通过array的index来访问对应的变量，这样也就保证了static和global的变量为每一个线程都创建不同的副本。

2）互锁函数的家族十分的庞大，例如InterlockedExchangeAdd（）。。。，使用互锁函数的优点是：他的速度要比其他的CriticalSection,Mutex,Event,Semaphore快很多。

3）等待函数，例如WaitForSingleObject 函数用来检测 hHandle 事件的信号状态，当函数的执行时间超过 dwMilliseconds 就返回，但如果参数 dwMilliseconds 为 INFINITE 时函数将直到相应时间事件变成有信号状态才返回，否则就一直等待下去，直到 WaitForSingleObject 有返回直才执行后面的代码。

六《Windows核心编程（英文版·第5版）》
最好的windows多线程编程参考，更多更详细请看原书。

梦在天涯 2008-07-29 22:54 发表评论

超越 C++ 下一代 C++ — C++/CLI简介（转载）

梦在天涯 — Fri, 18 Jul 2008 22:28:00 +0800

一、绪论

当微软推出VS.NET7实现了可扩展的托管C++后，C++程序员们反映不一。尽管大部分的程序员对于能够继续使用C++感到很欣慰，但几乎所有的人对于托管C++提供的晦涩语法感到很痛苦。微软明显从反馈中感觉到托管C++不是那么成功。

2003年10月6日，ECMA（欧洲计算机制造商协会）宣布成立专家组，负责结合ISO标准C++与通用语言，开发一个可扩展语言的标准，这个新的可扩展语言被称为C++/CLI标准。这个标准将被VS.NET2005的C++编译器支持。

二、老语法存在的问题

1、晦涩繁琐的语法和文法--这两个"双重底线"问题加重了阅读的负担。

2、二流的CLI支持--相对与C#与VB.NET，MC++使用不方便的工作区来提供CLI支持，例如，它没有一个一一对应的结构来列举.NET的集合。

3、C++与.NET粗陋地结合--对于CLI类型，你不能使用C++的特色，例如模板；同样，对于C++类型，你不能使用CLI的特色，例如碎片帐集。

4、令人混淆的指针--非托管的C++的指针及托管的引用指针都使用*语法，这非常令人混淆，因为-gc指针与托管指针在本质和行为上完全不同。

5、MFC编译器不能产生可校验的代码。

三、C++/CLI给我们提供了什么？

1、优雅流畅的语法和文法--C++/CLI为C++开发人员书写托管代码提供了一种非常自然的感觉，并且它提供了非托管代码到托管代码的平滑过度。以前所谓的"双重底线"问题现在已经荡然无存。

2、一流的CLI支持--CLI特色，例如属性、碎片集合和属类得到了直接支持，此外，C++/CLI还准许将这些特色用于本地非托管的类。

3、一流的C++类支持--C++特色，例如模板和析构函数对于拖管和非拖管类继续有效。实际上，C++/CLI是你可以"表面上"在栈或C++本地堆上声明一个.NET类型唯一的.NET语言。

4、在.NET与C++之间的沟壑上架起了一座桥梁--C++开发人员在抨击BCL时不再象离开水的鱼。

5、C++/CLI编译器产生的可执行文件完全是可校验的。

四、"Hello World"小程序

using namespace System;
            void _tmain()
            {
            Console::WriteLine("Hello World");
            }

上述代码除了不需要引用mscorlib.dll库外，与老的语法没有太大的区别，因为无论你什么时候使用/clr进行编辑，编译器都可以暗中进行引用（现在默认的是/clr:newSyntax）。

五、句柄

与老的语法主要的混淆是我们习惯于使用*符号来声明拖管引用或非拖管指针，在C++/CLI里微软引入了句柄的概念。

void _tmain()
            {
            //The ^ punctuator represents a handle
            String^ str = "Hello World";
            Console::WriteLine(str);
            }

^符号代表一个托管对象（声明时看上去象个帽子），按照CLI的规定，句柄代表一个拖管对象的引用。句柄在CLI中是新的语法，相当于C++中的-gc指针。句柄与指针不再混淆，在本质上两者完全不同。

六、句柄与指针是怎样区分开来的？

1、指针声明时使用*符号，而句柄使用^符号。

2、句柄是针对拖管堆上对象的拖管引用，而指针仅仅指向内存中的一个地址。

3、指针很稳定，GC循环不会影响到它；句柄在基于GC或内存紧张的情况下，可以指向不同的内存位置。

4、对于指针，程序开发人员必须"显式"地删除，否则会面临泄露的危险，而对于句柄，是否进行显式删除则完全根据程序人员的爱好了。

5、句柄一定要指向一个具体的类型，即所谓的类型安全性，而指针明显不是这样，你决不可以将一个句柄指向Void^类型。

6、正如new操作符返回一个指针一样，gcnew返回一个句柄。

七、CLR对象示例

void _tmain()
            {
            String^ str = gcnew String("Hello World");
            Object^ o1 = gcnew Object();
            Console::WriteLine(str);
            }

关键字gcnew用来实例化一个CLI对象，而且它返回一个指向在CLR堆上的对象的句柄，gcnew的优点在于它可以方便的让我们区分拖管和非拖管的实例对象。

大部分情况下，gcnew关键字和^操作符提供了你用来进行BCL的一切手段，但是很明显你需要创建和声明属于自己的拖管类和接口。

八、声明类型

CLR类型有一个形容词前缀用来说明类型的种类，下面是C++/CLI中的类型声明示例：

1、 CLR types
            o Reference types
            § ref class RefClass;
            § ref struct RefClass;
            2、 Value types
            § value class ValClass;
            § value struct ValClass;
            o Interfaces
            § interface class IType;
            § interface struct IType;
            o Enumerations
            § enum class Color;
            § enum struct Color;
            3、 Native types
            o class Native;
            o struct Native;
            示例：
            using namespace System;
            interface class IDog
            {
            void Bark();
            };
            ref class Dog : IDog
            {
            public:
            void Bark()
            {
            Console::WriteLine("Bow wow wow");
            }
            };
            void _tmain()
            {
            Dog^ d = gcnew Dog();
            d->Bark();
            }

上述程序中的代码与老的C++语言相比看上去非常简洁，在以往的C++代码中，至少要用到-gc和-interface这两个关键词。

九、装箱/拆箱操作

在C++/CLI中，加箱是隐含的，而且类型是安全的，一个二进制的拷贝被执行并在CLR堆上形成一个对象，去箱是显式的，仅仅需要使用reinterpret_cast操作符来解除引用。

void _tmain()
            {
            int z = 44;
            Object^ o = z; //implicit boxing
            int y = *reinterpret_cast<int^>(o); //unboxing
            Console::WriteLine("  ",o,z,y);
            z = 66;
            Console::WriteLine("  ",o,z,y);
            }
            // 输出结果如下：
            // 44 44 44
            // 44 66 44

在上述代码中，"o"对象是一个加箱的拷贝，从第二个语句Console::WriteLine.的输出可以很明显地看到，它并没有涉及到int类型的整数值。

当你对一种数值类型进行加箱操作时，返回的对象记住了最初的数值类型。

void _tmain()
            {
            int z = 44;
            float f = 33.567;
            Object^ o1 = z;
            Object^ o2 = f;
            Console::WriteLine(o1->GetType());
            Console::WriteLine(o2->GetType());
            }
            // Output
            // System.Int32
            // System.Single

因此不能对不同类型的对象进行去箱操作。

void _tmain()
            {
            int z = 44;
            float f = 33.567;
            Object^ o1 = z;
            Object^ o2 = f;
            int y = *reinterpret_cast<int^>(o2);//System.InvalidCastException
            float g = *reinterpret_cast<float^>(o1);//System.InvalidCastException
            }

如果你非尝试这么做，那么你将得到一个System.InvalidCastException。让我们来探讨一下完美的类型安全性，如果你要看内部代码，你将看到微软的内部箱在实际中的运用。例如：

void Box2()
            {
            float y=45;
            Object^ o1 = y;
            }

编译后的代码是：

.maxstack 1
            .locals (float32 V_0, object V_1)
            ldnull
            stloc.1
            ldc.r4 45.
            stloc.0
            ldloc.0
            box [mscorlib]System.Single
            stloc.1
            ret

根据微软的内部文档，箱操作将未加工的类型转换为一个具体类型的实例，这项工作的完成通过创建一个新的对象并将数据拷贝到这个新分配的对象。

十、写在后面的话

为什么很多人已经可以使用C、C++、.NET来开发程序但还在积极学习C++/CLI呢，我想有四个方面的原因：

1、从编译器直到内层都还在支持C++代码；

2、C++/CLI对于其他标准来说无意是具有毁灭性地；

3、与生俱来的内部支持胜过所有其他CLI语言

4、所有在MFC中出现的下划线都已不再存在。

梦在天涯 2008-07-18 22:28 发表评论

C++/CLI：第一流的CLI语言(转载)

梦在天涯 — Fri, 18 Jul 2008 22:12:00 +0800

C++/CLI：第一流的CLI语言
2005-08-25 11:25 作者：朱先忠编译出处：天极网责任编辑：方舟

1. 简介

　　本文并不是为了奉承C++/CLI的辉煌，也不是为了贬低其它如C#或者VB.NET等语言，相反，这只是一个非官方的、以一个喜欢这种语言的非微软雇员身份来论证C++/CLI有它的自己的唯一的角色，可作为第一流的.NET编程语言。

　　一个不断在新闻组和技术论坛上出现的问题是，当象C#和VB.NET这样的语言更适合于这种用途时，为什么要使用C++来开发.NET应用软件。通常这样一些问题后面的评论说是，C++语法是怎样的复杂和令人费解，C++现在是怎样一种过时的语言，还有什么VS.NET设计者已不再像支持C#和VB.NET一样继续支持C++。其中一些猜疑是完全荒谬的，但有些说法部分正确。希望本文有助于澄清所有这些围绕C++/CLI语言及其在VS.NET语言层次中的地位的疑惑，神秘和不信任。请记住，本作者既不为微软工作也没有从微软那里取得报酬，只是想从技术上对C++/CLI作一评判。

　　2. 快速简洁的本机interop

　　除了P/Invoke机制可用在另外的象C#或VB.NET这样的语言外，C++提供了一种独有的interop机制，称作C++ interop。C++ interop比P/Invoke直观得多，因为你只是简单地#include需要的头文件，并与需要的库进行链接就能象在本机C++中一样调用任何函数。另外，它比P/Invoke速度快--这是很容易能证明的。现在，可争辩的是在实际应用软件的开发中，经由C++ interop获得的性能好处与花在用户接口交互、数据库存取、网络数据转储、复杂数学算法等方面的时间相比可以被忽略，但是事实是在有些情况下，甚至通过每次interop调用节省的几个纳秒也能给全局应用程序性能/响应造成巨大影响，这是绝对不能被忽视的。下面有两部分代码片断(一个是使用P/Invoke机制的C#程序，一个是使用C++ Interop机制的C++程序)，我分别记录了其各自代码重复执行消耗的时间(毫秒)。不管你如何解释这些数据，不管这会对你的应用程序产生什么影响，全是你的事。我仅打算事实性地指出，C++代码的执行速度要比C#(其中使用了较多的本机interop调用)快。

　　1) C#程序(使用P/Invoke)

[SuppressUnmanagedCodeSecurity]
[DllImport("kernel32.dll")]
static extern uint GetTickCount();
[SuppressUnmanagedCodeSecurity]
[DllImport("kernel32.dll", SetLastError = true, CharSet = CharSet.Auto)]
static extern uint GetWindowsDirectory(
[Out] StringBuilder lpBuffer, uint uSize);
static void Test(int x)
{
StringBuilder sb = new StringBuilder(512);
for (int i = 0; i < x; i++)
GetWindowsDirectory(sb, 511);
}
static void DoTest(int x)
{
uint init = GetTickCount();
Test(x);
uint tot = GetTickCount() - init;
Console.WriteLine("Took {0} milli-seconds for {1} iterations",tot, x);
}
static void Main(string[] args)
{
DoTest(50000);DoTest(500000);DoTest(1000000);DoTest(5000000);
Console.ReadKey(true);
}

　　2) C++程序(使用C++ Interop)

void Test(int x)
{
TCHAR buff[512];
for(int i=0; i<x; i++)
GetWindowsDirectory(buff, 511);
}
void DoTest(int x)
{
DWORD init = GetTickCount();
Test(x);
DWORD tot = GetTickCount() - init;
Console::WriteLine("Took {0} milli-seconds for {1} iterations",tot, x);
}
int main(array<System::String ^> ^args)
{
DoTest(50000);DoTest(500000);DoTest(1000000);DoTest(5000000);
Console::ReadKey(true);
return 0;
}

　　3) 速度比较

重复次数	C# 程序	C++程序
50,000	61	10
500,000	600	70
1,000,000	1162	140
5,000,000	6369	721

　　
　　其性能差别真是令人惊愕！这的确是说明为什么要使用C++/CLI的一个好理由，如果你在使用本机interop进行开发，那么性能！完全由于性能，我就将被迫借助本机interop来实现并非基于web的.NET应用程序。当然，为什么我想要使用.NET来开发需要大量本机interop技术的应用程序完全是另外一个问题。

　　如果你仍怀疑这种性能优势，有另外的理由来说明你为什么不得不使用C++/CLI而不是C#或VB.NET——源码膨胀！下面是一个C++函数的例子，它使用了IP帮助者API来枚举一台机器上的网络适配器并且列出与每个适配器相联系的所有IP地址。

　　4) 枚举n/w适配器的C++代码

void ShowAdapInfo()
{
PIP_ADAPTER_INFO pAdapterInfo = NULL;
ULONG OutBufLen = 0;
//得到需要的缓冲区大小
if(GetAdaptersInfo(NULL,&OutBufLen)==ERROR_BUFFER_OVERFLOW)
{
int divisor = sizeof IP_ADAPTER_INFO;
#if _MSC_VER >= 1400
if( sizeof time_t == 8 ) divisor -= 8;
#endif
pAdapterInfo = new IP_ADAPTER_INFO[OutBufLen/divisor];
//取得适配器信息
if( GetAdaptersInfo(pAdapterInfo, &OutBufLen) != ERROR_SUCCESS )
{//调用失败 }
else
{
int index = 0;
while(pAdapterInfo)
{
Console::WriteLine(gcnew String(pAdapterInfo->Description));
Console::WriteLine("IP Address list : ");
PIP_ADDR_STRING pIpStr = &pAdapterInfo->IpAddressList;
while(pIpStr)
{
Console::WriteLine(gcnew tring(pIpStr->IpAddress.String));
pIpStr = pIpStr->Next;
}
pAdapterInfo = pAdapterInfo->Next;
Console::WriteLine();
}
}
delete[] pAdapterInfo;
}
}

　　现在让我们看一个使用P/Invoke的C#版本。

　　5) 使用P/Invoke技术的C#版本

const int MAX_ADAPTER_NAME_LENGTH = 256;
const int MAX_ADAPTER_DESCRIPTION_LENGTH = 128;
const int MAX_ADAPTER_ADDRESS_LENGTH = 8;
const int ERROR_BUFFER_OVERFLOW = 111;
const int ERROR_SUCCESS = 0;
[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Ansi)]
public struct IP_ADDRESS_STRING
{
[MarshalAs(UnmanagedType.ByValTStr, SizeConst = 16)]
public string Address;
}
[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Ansi)]
public struct IP_ADDR_STRING
{
public IntPtr Next;
public IP_ADDRESS_STRING IpAddress;
public IP_ADDRESS_STRING Mask;
public Int32 Context;
}
[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Ansi)]
public struct IP_ADAPTER_INFO
{
public IntPtr Next;
public Int32 ComboIndex;
[MarshalAs(UnmanagedType.ByValTStr,
SizeConst = MAX_ADAPTER_NAME_LENGTH + 4)]
public string AdapterName;
[MarshalAs(UnmanagedType.ByValTStr,
SizeConst = MAX_ADAPTER_DESCRIPTION_LENGTH + 4)]
public string AdapterDescription;
public UInt32 AddressLength;
[MarshalAs(UnmanagedType.ByValArray,
SizeConst = MAX_ADAPTER_ADDRESS_LENGTH)]
public byte[] Address;
public Int32 Index;
public UInt32 Type;
public UInt32 DhcpEnabled;
public IntPtr CurrentIpAddress;
public IP_ADDR_STRING IpAddressList;
public IP_ADDR_STRING GatewayList;
public IP_ADDR_STRING DhcpServer;
public bool HaveWins;
public IP_ADDR_STRING PrimaryWinsServer;
public IP_ADDR_STRING SecondaryWinsServer;
public Int32 LeaseObtained;
public Int32 LeaseExpires;
}
[DllImport("iphlpapi.dll", CharSet = CharSet.Ansi)]
public static extern int GetAdaptersInfo(IntPtr pAdapterInfo, ref int pBufOutLen);
static void ShowAdapInfo()
{
int OutBufLen = 0;
//得到需要的缓冲区大小
if( GetAdaptersInfo(IntPtr.Zero, ref OutBufLen) ==
ERROR_BUFFER_OVERFLOW )
{
IntPtr pAdapterInfo = Marshal.AllocHGlobal(OutBufLen);
//取得适配器信息
if( GetAdaptersInfo(pAdapterInfo, ref OutBufLen) != ERROR_SUCCESS )
{ //调用失败了 }
else{
while(pAdapterInfo != IntPtr.Zero)
{
IP_ADAPTER_INFO adapinfo =
(IP_ADAPTER_INFO)Marshal.PtrToStructure(
pAdapterInfo, typeof(IP_ADAPTER_INFO));
Console.WriteLine(adapinfo.AdapterDescription);
Console.WriteLine("IP Address list : ");
IP_ADDR_STRING pIpStr = adapinfo.IpAddressList;
while (true){
Console.WriteLine(pIpStr.IpAddress.Address);
IntPtr pNext = pIpStr.Next;
if (pNext == IntPtr.Zero)
break;
pIpStr = (IP_ADDR_STRING)Marshal.PtrToStructure(
pNext, typeof(IP_ADDR_STRING));
}
pAdapterInfo = adapinfo.Next;
Console.WriteLine();
}
}
Marshal.FreeHGlobal(pAdapterInfo);
}
}

3. 栈语义和确定性的析构

　　C++经由栈语义模仿给了我们确定性的析构。简言之，栈语义是Dispose模式的良好的语法替代品。但是它在语义上比C# using块语法更直观些。请看下列的C#和C++代码段（都做一样的事情-连接两个文件的内容并把它写到第三个文件中）。

　　1) C#代码--使用块语义

public static void ConcatFilestoFile(String file1, String file2, String outfile)
{
String str;
try{
using (StreamReader tr1 = new StreamReader(file1))
{
using (StreamReader tr2 = new StreamReader(file2))
{
using (StreamWriter sw = new StreamWriter(outfile))
{
while ((str = tr1.ReadLine()) != null)
sw.WriteLine(str);
while ((str = tr2.ReadLine()) != null)
sw.WriteLine(str);
}
}
}
}
catch (Exception e)
{ Console.WriteLine(e.Message); }
}

　　2) C++代码--栈语义

static void ConcatFilestoFile(String^ file1, String^ file2, String^ outfile)
{
String^ str;
try{
StreamReader tr1(file1);
StreamReader tr2(file2);
StreamWriter sw(outfile);
while(str = tr1.ReadLine())
sw.WriteLine(str);
while(str = tr2.ReadLine())
sw.WriteLine(str);
}
catch(Exception^ e)
{ Console::WriteLine(e->Message); }
}

　　C#代码与相等的C++ 代码相比不仅免不了冗长，而且using块语法让程序员自己明确地指定他想在哪儿调用Dispose（using块的结束处），而使用C++/CLI的栈语义，只需让编译器使用常规的范围规则来处理它即可。事实上，这使得在C#中修改代码比在C++中更乏味-作为一实例，让我们修改这些代码以便即使仅存在一个输入文件也能创建输出文件。请看下面修改后的C#和C++代码。

　　3) 修改后的C#代码

public static void ConcatFilestoFile(String file1, String file2, String outfile)
{
String str;
try{
using (StreamWriter sw = new StreamWriter(outfile))
{
try{
using (StreamReader tr1 = new StreamReader(file1))
{
while ((str = tr1.ReadLine()) != null)
sw.WriteLine(str);
}
}
catch (Exception) { }
using (StreamReader tr2 = new StreamReader(file2))
{
while ((str = tr2.ReadLine()) != null)
sw.WriteLine(str);
}
}
}
catch (Exception e){ }
}

　　把针对StreamWriter的using块放到顶层需要重新调整using块结构--这在上面情况下显然不是个大问题，但是对于实际开发中的修改，这可能是相当模糊的且易导致逻辑错误的。

　　4) 修改后的C++代码

static void ConcatFilestoFile(String^ file1, String^ file2, String^ outfile)
{
String^ str;
try{
StreamWriter sw(outfile);
try{
StreamReader tr1(file1);
while(str = tr1.ReadLine())
sw.WriteLine(str);
}
catch(Exception^){}
StreamReader tr2(file2);
while(str = tr2.ReadLine())
sw.WriteLine(str);
}
catch(Exception^){}
}

　　这样不是比在C#中的做更容易些吗？我恰好把StreamWriter声明移到了顶部并增加了一个额外的try块，就这些。甚至对于象在我的示例代码片断中的琐碎事情，如果所涉及的复杂性在C++中大大减少，那么，当你工作于更大的工程时你能想象使用栈语义对你的编码效率千万的影响。

　　还不确信？好，让我们看一下成员对象和它们的析构吧。Imagine CLI GC类R1和R2，二者都实现了Idisposable接口且都有函数F()，还有一个CLI GC类R，它有R1和R2成员和一个函数F()-它内部地调用R1和R2上的F()成员函数。让我们先看C#实现。

　　5) 一个disposable类继承层次的C#实现

class R1 : IDisposable{
public void Dispose() { }
public void F() { }
}
class R2 : IDisposable{
public void Dispose() { }
public void F() { }
}
class R : IDisposable{
R1 m_r1 = new R1();
R2 m_r2 = new R2();
public void Dispose()
{
m_r1.Dispose();
m_r2.Dispose();
}
public void F()
{
m_r1.F();
m_r2.F();
}
public static void CallR()
{
using(R r = new R())
{r.F();}
}
}

　　这里有几件事情要做：必须为每个disposable 类手工实现IDisposable接口，对于具有成员R1和R2的类R，Dispose方法也需要调用成员类上的Dispose。现在让我们分析上面几个类的C++实现。

　　6) 等价的C++实现

ref class R1
{
public:
~R1(){}
void F(){}
};
ref class R2
{
public:
~R2(){}
void F(){}
};
ref class R
{
R1 m_r1;
R2 m_r2;
public:
~R(){}
void F()
{
m_r1.F();
m_r2.F();
}
static void CallR()
{
R r;
r.F();
}
};

　　注意，这里不再有手工的Idisposable接口实现(我们的类中仅建立了析构器)而且最好的部分--类R的析构器(Dispose方法)并没有在该类可能含有的可释放的成员上调用Dispose-它没有必要这样做，编译器自动为之生成所有的代码！

4. 混合类型

　　我们知道，C++支持本机类型-总是如此；C++支持CLI类型-本文正是特别强调这一点；它还支持混合类型-具有CLI成员的本机类型和具有本机成员的CLI类型！请尽管考虑所有你能的可能需求。

　　注意，谈到Whidbey，混合类型实现还不完整；就我从Brandon，Herb和Ronald发表的材料的理解得知，存在这种相当酷的类型--统一模型，它将在Orcas中实现--你能够在本机C++堆上new/delete CLI类型，而且也能够在CLI堆上gcnew/delete本机类型。但既然这是Whidbey以后的东西，本文不讨论统一模型。

　　在我谈论你何时使用混合类型以前，我想向你说明什么是混合类型。如果你理解混合类型，请跳过下面几段。这里引用Brandon Bray的说法："一种混合类型，或者是本机类ref类（需要有对象成员），或者是通过声明或继承被分配在垃圾回收堆或本机堆上的。"因此如果你有一个托管类型或者有一个有托管成员的本机类型，你就有了一个混合类型。VC++ Whidbey不直接支持混合类型(统一类型模型是一种Whidbey之后的概念)，但是它给我们划定了实现混合类型的条件。让我们开始讨论包含托管成员的本机类型。

ref class R
{
public:
void F(){}
//假定 non-trivial ctor/dtor
R(){}
~R(){}
};

　　在我的例子中，设想该托管类型R有一个non-trivial构造器和一个non-trivial析构器。

class Native
{
private:
gcroot<R^> m_ref;
public:
Native():
m_ref(gcnew R()){}
~Native()
{ delete m_ref; }
void DoF()
{ m_ref->F(); }
};

　　既然，我不能在我的类中拥有一个R成员，我使用了gcroot模板类(在gcroot.h中声明，但是你要用"#include vcclr.h")，它包装了System::Runtime::InteropServices::GCHandle结构。它是个象类一样的灵敏指针，它重载了运算符->以返回用作模板参数的托管类型。因此在上面类中，我可以使用m_ref，就好象我已经声明它是R^，而且你能在DoF函数中看到这正在起作用。实际上你可以节省delete，这可以通过使用auto_gcroot(类似于std::auto_ptr，在msclr\auto_gcroot.h文件中声明)代替gcroot来实现。下面是一个更好些的使用auto_gcroot的实现。

class NativeEx
{
private:
msclr::auto_gcroot<R^> m_ref;
public:
NativeEx() : m_ref(gcnew R()){}
void DoF()
{ m_ref->F(); }
};

　　下面让我们看相反的情形：一个CLI类的本机成员。

ref class Managed
{
private:
Native* m_nat;
public:
Managed():m_nat(new Native()){ }
~Managed()
{ delete m_nat; }
!Managed()
{ delete m_nat;
#ifdef _DEBUG
throw gcnew Exception("Oh, finalizer got called!");
#endif
}
void DoF()
{ m_nat->DoF(); }
};

　　我不能定义一个Native对象来作为一个ref类成员，因此需要使用一个Native*对象来代替。我在构造器中new该Native对象，然后在析构器和finalizer中delete它。如果你运行该工程的调试版，在执行到finalizer时将抛出一个异常- 因此开发者可以马上添加一个对delete的调用或为他的CLI类型使用栈语义技术。奇怪的是，库开发小组没有建立一个gcroot的反向实现-但这不是个大问题，我们可以自己写。

template<typename T> ref class nativeroot
{
T* m_t;
public:
nativeroot():m_t(new T){}
nativeroot(T* t):m_t(t){}
T* operator->()
{ return m_t; }
protected:
~nativeroot()
{ delete m_t; }
!nativeroot()
{
delete m_t;
#ifdef _DEBUG
throw gcnew Exception("Uh oh, finalizer got called!");
#endif
}
};

　　这仅是个相当简单的灵敏指针实现，就象一个负责本机对象分配/回收的ref类。不管怎样，借助nativeroot模板类，我们可以如下修改托管类：

ref class ManagedEx
{
private:
nativeroot<Native> m_nat;
public:
void DoF()
{ m_nat->DoF(); }
};

　　好，关于混合类型的最大问题是什么呢？你可能问。最大问题是，现在你能混合使用你的MFC、ATL、WTL、STL代码仓库和.NET框架，并用可能的最直接的方式-只需写你的混合模式代码并编译实现!你可以建立在一个DLL库中建立MFC 类，然后建立一个.NET应用程序来调用这个DLL，还需要把.NET类成员添加到你的MFC类（也实现可以相反的情况）。

　　作为一例，设想你有一MFC对话框--它通过一个多行的编辑框接受来自用户的数据-现在，你有一新的要求-显示一个只读编辑框，它将显示当前在该多行编辑框中文本的md5哈希结果。你的队友正在悲叹他们将必须花费几个小时钻研crypto API，而你的上司在担忧你们可能必须要买一个第三方加密库；那正是你在他们面前树立形象的时候，你宣布你将在15分钟内做完这项任务。下面是解决的办法：

　　添加一个新的编辑框到你的对话框资源中，并且添加相应的DDX变量。选择/clr编译模式并且添加下列代码到你的对话框的头文件中：

#include <msclr\auto_gcroot.h>
using namespace System::Security::Cryptography;

　　使用auto_gcroot模板来声明一个MD5CryptoServiceProvider成员：

protected:
msclr::auto_gcroot<MD5CryptoServiceProvider^> md5;

　　在OnInitDialog过程中，gcnew MD5CryptoServiceProvider成员。

md5 = gcnew MD5CryptoServiceProvider();

　　并且为多行编辑框添加一个EN_CHANGE处理器：

void CXxxxxxDlg::OnEnChangeEdit1()
{
using namespace System;
CString str;
m_mesgedit.GetWindowText(str);
array<Byte>^ data = gcnew array<Byte>(str.GetLength());
for(int i=0; i<str.GetLength(); i++)
data[i] = static_cast<Byte>(str[i]);
array<Byte>^ hash = md5->ComputeHash(data);
CString strhash;
for each(Byte b in hash)
{
str.Format(_T("%2X "),b);
strhash += str;
}
m_md5edit.SetWindowText(strhash);
}

　　这里使用了混合类型：一个本机Cdialog派生类，该类含有一个MD5CryptoServiceProvider成员(CLI类型)。你可以轻易地试验相反的情况（如早期的代码片断已显示的）——可以建立一个Windows表单应用程序而且可能想利用一个本机类库--这不成问题，使用上面定义的模板nativeroot即可。

5. 托管模板

　　也许你对泛型的概念已很清楚了，它帮助你避免进入C++的模板梦魇，它是实现模板的最佳方式，等等。好，假设这些全部正确，C++/CLI支持泛型就象任何其它CLI语言一样-但是它有而其它一些CLI语言还没有的是它还支持托管模板-也就是模板化的ref和value类。如果你以前从未使用过模板，你不能一下欣赏这么多优点，但是如果你有模板使用背景而且你已发现了泛型中存在的可能限制你编码的方式，托管模板将会大大减轻你的负担。你能联合使用泛型和模板- 事实上有可能用一个托管类型的模板参数来实例化一个泛型类型(尽管相反的情形是不可能的，因为运行时刻实例化由泛型所用)。STL.NET (或STL/CLR)以后讨论，请很好地利用泛型和托管模板的混合编程吧。

　　泛型使用的子类型约束机制将防止你写出下面的代码：

generic<typename T> T Add(T t1, T t2)
{ return t1 + t2; }

　　编译错误：

error C2676: binary ’+’ : ’T’ does not define this operator or a conversion to a type acceptable to the predefined operator

　　现在请看相应的模板版本：

template<typename T> T Add(T t1, T t2)
{ return t1 + t2; }

　　那么就可以这样做：

int x1 = 10, x2 = 20;
int xsum = Add<int>(x1, x2);

　　还可以这样做：

ref class R
{
int x;
public:
R(int n):x(n){}
R^ operator+(R^ r)
{ return gcnew R(x + r->x); }
};
//...
R^ r1 = gcnew R(10);
R^ r2 = gcnew R(20);
R^ rsum = Add<R^>(r1, r2);

　　这在一个象int的本机类型以及一个ref类型(只要ref类型有一个+运算符)情况下都能工作良好。这个泛型缺点不是一个调试错误或缺陷-它是设计造成的。泛型的实例化是在运行时通过调用配件集实现的，因此编译器不能确知一特定操作能被施行于一个泛型参数，除非它匹配一个子类型约束，因此编译器在定义泛型时解决这个问题。当你使用泛型时的另外一个妨碍是，它不会允许你使用非类型参数。下列泛型类定义不会编译：

generic<typename T, int x> ref class G{};

　　编译错：

error C2978: syntax error : expected ’typename’ or ’class’; found type ’int’; non-type parameters are not supported in generics

　　与托管模板相比较：

template<typename T, int x = 0> ref class R{};

　　如果你开始感激C++向你提供了泛型和托管模板，那么请看下面这一个例子：

template<typename T> ref class R{
public:
void F()
{ Console::WriteLine("hey"); }
};
template<> ref class R<int>
{
public:
void F()
{ Console::WriteLine("int"); }
};

　　你不能用泛型这样编码；否则，将产生：

　　编译错：error C2979: explicit specializations are not supported in generics

　　但可以在继承链中混合使用模板和泛型：

generic<typename T> ref class Base
{
public:
void F1(T){}
};
template<typename T> ref class Derived : Base<T>
{
public:
void F2(T){}
};
//...
Derived<int> d;
d.F1(10);
d.F2(10);

　　最后，你不能从一个泛型参数类型派生一个泛型类。

　　下列代码不会成功编译：

generic<typename T> ref class R : T
{};

　　error C3234: a generic class may not derive from a generic type parameter

　　模板让你这样做(好像你还不知道这些)：

ref class Base{
public:
void F(){}
};
generic<typename T> ref class R : T
{};
//...
R<Base> r1;
r1.F();

　　这样，当你下次遇到对泛型的贬谤时，你就知道该怎么做了。

　　6. STL/CLR

　　当大量使用STL的C++开发者转向.NET1/1.1时一定感觉非常别扭，他们中的许多可能会放弃并转回到原来的本机编码。从技术上讲，你能结合.NET类型(using gcroot)使用本机STL，但是产生的结果代码可能相当低效，更不用说是丑陋了：

std::vector< gcroot<IntPtr> >* m_vec_hglobal;
//...
for each(gcroot<IntPtr> ptr in *m_vec_hglobal)
{ Marshal::FreeHGlobal(ptr);}

　　大概VC++小组考虑到了这些并决定在Whidbey以后，他们会提供STL.NET（或STL/CLR）并可以单独从网上下载。

　　你可能问为什么？Stan Lippman，在他的MSDN文章(STL.NET Primer)中给出了3条原因：

　　·可扩展性--STL设计把算法和容器隔离到自己的应用空间-也就是你可以有一组容器和一组算法，并且你能在任何一个容器上使用这些算法；同时你能在任何一个算法中使用这些容器。因此，如果你添加一种新的算法，你能在任何一种容器中使用它；同样，一个新的容器也可以与现有算法配合使用。

　　·统一性--所有核心C++开发者集中在一起，汇集起他们精妙的STL专长，再使用他们的专长则轻车熟路。要较好地使用STL需要花费时间-然而一旦你掌握了它，你就有了在.NET世界中使用你的技巧的明显优势。不是吗？

　　·性能--STL.NET通过使用实现泛型接口的托管模板实现。并且既然它的核心已用C++和托管模板编码，可以期盼它比在BCL上使用的泛型容器更具有性能优势。

　　使用过STL的人不需要任何示范，所以下面代码有益于以前没有使用过STL的人。

vector<String^> vecstr;
vecstr.push_back("wally");
vecstr.push_back("nish");
vecstr.push_back("smitha");
vecstr.push_back("nivi");
deque<String^> deqstr;
deqstr.push_back("wally");
deqstr.push_back("nish");
deqstr.push_back("smitha");
deqstr.push_back("nivi");

　　我使用了两个STL.NET容器-vector和deque，并装满两个容器，使其看起来相同(在两个容器中都使用了push_back)。现在，我将在两个容器上使用replace算法-我们再次看到，这些代码是很相同的。

replace(vecstr.begin(), vecstr.end(),
gcnew String("nish"), gcnew String("jambo"));
replace(deqstr.begin(), deqstr.end(),
gcnew String("nish"), gcnew String("chris"));

　　这里特别要注意的是我使用了"同样"的算法--replace并在两个不同STL容器上使用相同的函数调用。这是当Stan谈及"可扩展性"时的意思。下面我用一个简单函数来证明：

template<typename ForwardIterator> void Capitalize(
ForwardIterator first，ForwardIterator end)
{
for(ForwardIterator it = first; it < end; it++)
*it = (*it)->ToUpper();
}

　　它遍历一个System::String^容器并把其中的每个字符串转化为大写。

Capitalize(vecstr.begin(), vecstr.end());
Capitalize(deqstr.begin(), deqstr.end());
for(vector<String^>::iterator it = vecstr.begin();
it < vecstr.end(); it++)
Console::WriteLine(*it);
Console::WriteLine();
for(deque<String^>::iterator it = deqstr.begin();
it < deqstr.end(); it++)
Console::WriteLine(*it);

　　上面我的算法能够与vector和deque容器工作良好。至此，不再细谈；否则，guru站上的STL爱好者们会对我群起攻击，而非STL人可能感到厌烦。如果你还没使用过STL，可以参考有关资料。

7. 熟悉的语法

　　开发者经常迷恋他们所用的编程语言，而很少是出于实用的目的。还记得当微软宣布不再为VB6提供官方支持时，VB6人的反抗吗？非VB6人对此可能非常震惊，而老道的VB6人早已为他们的语言作好葬礼准备了。事实上，如果VB.NET从来没被发明，多数VB6人将会离开.NET，因为C#将会对他们非常陌生，而它的祖先就是C++。如今，许多VB.NET人可能已经转向了C#，但是他们不会从VB6直接转向C#；VB.NET起到一个桥梁作用让他们的思想脱离开原来VB6思想。相应地，如果微软仅发行VB.NET(而没有C#)，那么.NET可能成为了新的面向对象VB，且带有一个更大的类库-C++社团的人可能对此嗤之以鼻-他们甚至不会麻烦地检验.NET基础类库。为什么任何使用一种特定语言的开发者会对另外一个团体的使用另外开发语言的开发者嗤之以鼻？这不是我要回答的问题。--要回答该问题也许要先回答为什么有的人喜欢威士忌，有的人喜欢可口可乐，而还有人喜欢牛奶。所有我要说的是，对开发者来说，语法家族是个大问题。

　　你认为对于一个具有C++背景的人，下面的代码具有怎样的直觉性？

char[] arr =new char[128];

　　他/她可能回答的第一件事是，方括号放错了位置。下面这句又如何？

int y=arr.Length;

　　"呀!"-最可能的反映。现在把下面与前面相比较：

char natarr[128];
array<char>^ refarr=gcnew array<char>(128);
int y=refarr->Length;

　　请注意声明一个本机数组和一个托管数组时的语法区别。这里不同的模板形式的语法可视化地告诫开发者这一事实--refarr并不是典型的C++数组而且它可能是某种CLI类的派生物(事实上确是如此)，所以极有可能可以把方法和属性应用于它。

　　C#的finalizer语法最有可能引起转向C#的C++程序员的混淆。请看见下列C#代码：

class R
{ ~R(){} }

　　好，这样~R看起来象一个析构器但实际是个finalizer。为什么？请与下面的C++代码比较：

ref class R
{
~R(){ }
!R(){ }
};

　　这里~R是析构器（实际上等价于一个析构器的Dispose模式-但对C++人员来说，这它的行为象个析构器）而新的!R语法是为finalizer建立的-这样就不再有混淆而且语法看上去也与本机C++相匹配。

　　请看一下C#泛型语法：

class R<T>{};

　　再请看一下C++的语法：

generic<typename T> ref class R{};

　　曾经使用过模板的人马上就看出这种C++语法，而C#语法不能保证其没有混淆性且也不直观。我的观点是，如果你以前具有C++背景，C++/CLI语法将最贴近于你以前所用。C#(以及J#)看上去象C++，但是还有相当多的极为使人烦火的奇怪语义差别而且如果你没有完全放弃C++，语法差别将永远不停地带给你混乱和挫折。从这种意义上说，我认为VB.NET更好些，至少它有自己唯一的语法，所以那些共用C++和VB.NET的人不会产生语法混乱。

　　8. 结论

　　最后，至于你用什么语言编程，这可能依赖许多因素——如：你在学校学习的是什么语言，你是用什么语言开发的现有代码仓库，是否你的客户对你有具体的语言要求等。本文的主要目的是帮助你确定使用C++/CLI的几个明确的场所--这里，它比另外CLI语言更具有明显优势。如果你开发的应用程序有90%的使用时间是涉及本机interop，为何还要考虑使用另外的而不是C++？如果你想开发一个通用集合，为什么仅把你自己限制在泛型上，而不是结合泛型和模板的优势呢？如果你已经用C++工作，为什么还要学习一种新的语言?我常觉得象C#和VB.NET这样的语言总是尽量向开发者隐藏CLR，而C++不仅让你品味CLR，甚至可以让你去亲吻CLR!

梦在天涯 2008-07-18 22:12 发表评论

《Windwos via C++》之精华

梦在天涯 — Sun, 13 Jul 2008 10:37:00 +0800

来自：梦在天涯C++博客(http://www.cppblog.com/mzty/)

一引言

作为一名windows系统上图形软件开发者已经有3个多年头了，在此过程中有不少的经历和经验，非常高兴与大家分享，今天主要是《windows via C++》一书的阅读心得，所以主要谈到的是windows上C++的开发。

二 C++语言

我们知道C++是一门ISO的面向对象的语言，下面我介绍他的三个方面，也正是这三个主要方面决定了他被广泛的使用。第一，C++是一个功能强大的语言。比如C++语言本身提供的基于C语言的内嵌类型，数组，结构体和指针等，C++比C新加入的面向对象的Class，继承，多态和模板等，还有C++标准模板库（STL）提供的实际开发当中常用的数据结构和算法的实现；第二，大量的开源和第三方库，如果在windows上使用C++开发，我们还可以借助microsoft对C++提供的强有力的支持，首先的VS编译器，还有UI库MFC，还有ATL等；除此之外我们还可以看到其他的许多非microsoft的开源的和第三方的支持，比如说Boost很大程度的扩充了STL，提供了更多更高级的功能，还有Loki把C++与设计模式结合起来，还有很多的第三方的UI库，比如QT，WxWindows，WTL，GTK等，第三方的网络通信库，比如ACE，StreamModule等，第三那的XML库，比如Xerces，CMarkup，tinyxml等，第三方的科学计算库，比如Blitz++，MTL等，第三方的游戏开发库，比如OGRE，KlayGE等，第三方的线程库，比如C++ Threads，ZThreads等，还有其他的很多。第三，C++的高性能。这个也是毋庸质疑的，我们知道的大部分的操作系统，嵌入式开发，游戏，图像软件离不开C++，这都是跟C++的高性能有很大的关系。但从这一点来看，这就是很多现代的其他的高级语言没有的，所以C++以后仍然有很长的路要走。

三《Windows via c++》之经典

上面说了C++语言本身，这里具体到windows系统上C++的开发，我们要基于windows系统开发软件，就难免的要和windows系统打交道，比如系统本身对字符编码的支持，系统的异常处理机制，线程的创建管理，进程的创建管理，内存和虚拟内存的使用，堆栈的操作，DLL的使用等。上面提到的这些都不是C++语言本身的职责，是需要操作系统提供的支持，而所有这些内容正是《windows via C++》所覆盖的内容，也正是本书很好的把C++和Windows连接起来，引领C++程序员走向windows的底层，这也正是本书的经典之处!再次感谢作者Jeffrey Richter的伟大贡献！

1）字符编码：字符编码作为字符串的基础，自然而然就成了我们软件开发必不可缺少的基石，那么什么是字符编码那？字符编码就是字符在计算机内部的表示形式，我们都知道在计算机内部，所有的信息最终都表示为一个二进制的字符串。每一个二进制位（bit）有0和1两种状态，因此八个二进制位就可以组合出256种状态，这被称为一个字节（byte）。上个世纪60年代，美国制定了一套字符编码，对英语字符与二进制位之间的关系，做了统一规定。这被称为ASCII码，一直沿用至今。ASCII码一共规定了128个字符的编码，因为他只占用了一个字节的后面7位，最前面的1位统一规定为0。英语用128个符号编码就够了，但是用来表示其他语言，128个符号是不够的。所以后来就各国有了各国的编码，比如日文中的汉字远远大于256个，所以日文使用如果第一个字符在0 x 8 1 与0 x 9 F 之间，或者在0 x E 0 与0 x F C 之间，那么就必须观察下一个字节，才能确定字符串中的这个完整的字符。这样他就使用一个或两个字节来表示一个字符，这种编码被称为双字节字符集（D B C S ）。由于世界上存在着多种编码方式，这使得同一个二进制数字可以被解释成不同的符号。因此，要想打开一个文本文件，就必须知道它的编码方式，否则用错误的编码方式解读，就会出现乱码。这个时候Unicode就出现了他将世界上所有的符号都纳入其中。每一个符号都给予一个独一无二的编码，那么乱码问题就会消失。但是unicode也有不同的实现，主要的有三种：UTF-16：其本身就是标准的Unicode编码方案，又称为UCS-2，它固定使用16 bits(两个字节)整数来表示一个字符。UTF-32：又称为UCS-4，它固定使用32 bits(四个字节)整数来表示一个字符。UTF -8：最广泛的使用的UTF方案，UTF-8使用可变长度字节来储存Unicode字符，例如ASCII字母继续使用1字节储存，重音文字、希腊字母或西里尔字母等使用2字节来储存，而常用的汉字就要使用3字节。辅助平面字符则使用4字节。UTF-8更便于在使用Unicode的系统与现存的单字节的系统进行数据传输和交换。与前两个方案不同：UTF-8以字节为编码单元，没有字节序的问题。但是不管是哪种unicode的实现都可以包含世界所有的字符，解决软件本地化的难题。

Windows在2000以前使用ASCII，2000及以后的系统都使用unicode来编码，但是需要注意的是Windows2000既支持Unicode，也支持ANSI，因此可以为任意一种开发应用程序.如果调用任何一个Windows函数并给它传递一个ANSI字符串，那么系统首先要将字符串转换成Unicode，然后将Unicode字符串传递给操作系统。如果希望函数返回ANSI字符串，系统就会首先将Unicode字符串转换成ANSI字符串，然后将结果返回给你的应用程序。所有这些转换操作都是在你看不见的情况下发生的。当然，进行这些字符串的转换需要占用系统的时间和内存。比如同一个函数CreateWindowEx()，在内部其实是当ASCII是调用CreateWindowExA()，而当unicode时调用CreateWindowExW()。同时windows系统还给我们提供了ASCII和unicode间的转化函数MultiByteToWideChar(）和WideCharToMultiByte()。

2）进程和线程：进程通常被定义为一个正在运行的程序的实例，它由两个部分组成，第一，一个是操作系统用来管理进程的内核对象，内核对象也是系统用来存放关于进程的统计信息的地方；第二，是地址空间，它包含所有可执行模块或 D L L 模块的代码和数据，它还包含动态内存分配的空间，如线程堆栈和堆分配空间。线程是应用程序执行时的最小单位，同样线程也是由两个部分组成的：第一，一个是线程的内核对象，操作系统用它来对线程实施管理，内核对象也是系统用来存放线程统计信息的地方；第二，线程堆栈，它用于维护线程在执行代码时需要的所有函数参数和局部变量。

进程是不活泼的，从来不执行任何东西，它只是线程的容器，若要使进程完成某项操作，它必须拥有一个在它的环境中运行的线程，该线程负责执行包含在进程的地址空间中的代码，当创建一个进程时，系统会自动创建它的第一个线程，称为主线程，然后，该线程可以创建其他的线程，而这些线程又能创建更多的线程。如果在单进程环境中，你有两个或多个线程正在运行，那么这两个线程将共享单个地址空间。这些线程能够执行相同的代码，对相同的数据进行操作。这些线程还能共享内核对象句柄，因为句柄表依赖于每个进程而不是每个线程存在。

windows提供和很多函数来创建和管理线程和进程，比如CreateThread（），ExitThread（），TerminateThread（），GetCurrentThread()，CreateProcess（），ExitProcess（），TerminateProcess （），GetCurrentProcess（）等。

3）线程同步和线程局部存储：由于同一进程的所有线程共享进程的虚拟地址空间，并且线程的中断是汇编语言级的，所以可能会发生两个线程同时访问同一个对象（包括全局变量、共享资源、API函数和MFC对象等）的情况，这有可能导致程序错误。属于不同进程的线程在同时访问同一内存区域或共享资源时，也会存在同样的问题。因此，在多线程应用程序中，常常需要采取一些措施来同步线程的执行。

windows提供了3中同步机制，分别是信号量Semaphore，互斥量Mutex，关键代码段CriticalSection。其中信号量Semaphore，是一个可以限制对指定的临界段进行访问的线程的数目的数据结构。互斥量Mutex和关键代码段CriticalSection，他们的作用是相同的，都是用来保证某时刻只有一个线程能够访问全局或静态的资源。区别是：Mutex是内核对象，可以设置等待超时时间，可以在不同的进程的线程中使用，但是所消耗的时间也比较多。CriticalSection与Mutex相反。

线程局部存储（TLS），可以为全局或静态变量对不同的线程有不同的拷贝。

4）线程池：可以实现在程序中根据需要动态的创建线程，比如在server端，根据访问的用户的多少来创建线程的多少。在windows2000以后增加了创建线程池的API，比如 QueueUserWorkItem（）。

5) 纤程：用户级的线程机制，比线程小的单位，开发人员负责管理纤程的调度，同时负责确定纤程何时在线程时间片上下文中运行，一般不会带来性能的提高，主要的目的是为开发人员调度多个不需要并行执行的任务提供一个便捷的机制。单线程可以包含一个或多个纤程。就内核而言，线程是抢占调度的，是正在执行的代码。然而，线程每次执行一个纤程的代码，你决定究竟执行哪个纤程，你可以调用ConvertThreadToFiber（）将已有的线程转化位纤程，当对纤程的执行环境进行分配和初始化后，就可以将执行环境的地址与线程关联起来，该线程被转换成一个纤程，而纤程则在该线程上运行。现在，如果你的纤程（线程）返回或调用ExitThread函数，那么纤程和线程都会终止运行。除非打算创建更多的纤程以便在同一个线程上运行，否则没有理由将线程转换成纤程。若要创建另一个纤程，该线程（当前正在运行纤程的线程）可以调用CreateFiber函数。但是调用CreateFilber创建的纤程并不执行，直到调用SwitchToFiber函数。若要撤消纤程，可以调用DeleteFiber函数。

6) 作业：作业可以看作是一组进程的容器,把这些进程当作一个整体,对这个整体整个加入更多的限制. 因为Windows并不维护进程之间的父/子关系。即使父进程已经终止运行，子进程仍然会继续运行。Microsoft Windoss 2000提供了一个新的作业内核对象，使你能够将进程组合在一起，并且创建一个“沙框”，以便限制进程能够进行的操作。最好将作业对象视为一个进程的容器。但是，创建包含单个进程的作业是有用的，因为这样一来，就可以对该进程加上通常情况下不能加的限制。创建一个新作业内核对象可以调用CreateJobObject（），另一个进程要访问作业，可以通过OpenJobObject（），应该知道，关闭作业对象并不会迫使作业中的所有进程终止运行。该作业对象实际上做上了删除标记，只有当作业中的所有进程全部终止运行之后，该作业对象才被自动撤消。注意，关闭作业的句柄后，尽管该作业仍然存在，但是该作业将无法被所有进程访问。通过调用SetInformationJobObject()可以给作业加上各种限制.查询限制QueryInformationJobObject（），将进程放入作业AssignProcessToJobObject（），若要撤销作业中的进程调用TerminateJobObject（）。

7) 虚拟内存，内存映射文件和堆栈：每个进程都被赋予它自己的虚拟地址空间。对于3 2位进程来说，这个地址空间是4 G B,其中默认有2G是用户可以使用的。由于每个进程可以接收它自己的私有的地址空间，因此当进程中的一个线程正在运行时，该线程可以访问只属于它的进程的内存。属于所有其他进程的内存则隐藏着，并且不能被正在运行的线程访问。注意在Windows 2000中，属于操作系统本身的内存也是隐藏的，正在运行的线程无法访问。这意味着线程常常不能访问操作系统的数据。

Windows提供了3种进行内存管理的方法，它们是第一，虚拟内存，最适合用来管理大型对象或结构数组。第二，内存映射文件，最适合用来管理大型数据流（通常来自文件）以及在单个计算机上运行的多个进程之间共享数据。第三，内存堆栈，最适合用来管理大量的小对象。

在较老的操作系统中，物理存储器被视为计算机拥有的R A M的容量。换句话说，如果计算机拥有1 6 M B的R A M，那么加载和运行的应用程序最多可以使用1 6 M B的R A M。今天的操作系统能够使得磁盘空间看上去就像内存一样。磁盘上的文件通常称为页文件，它包含了可供所有进程使用的虚拟内存。

内存映射文件与虚拟内存一样，内存映射文件可以用来保留一个地址空间的区域，并将物理存储器提交给该区域。它们之间的差别是，物理存储器来自一个已经位于磁盘上的文件，而不是系统的页文件。一旦该文件被映射，就可以访问它，就像整个文件已经加载内存一样。

堆栈可以用来分配许多较小的数据块。例如，若要对链接表和链接树进行管理，最好的方法是使用堆栈，堆栈的优点是，可以不考虑分配粒度和页面边界之类的问题，集中精力处理手头的任务。堆栈的缺点是，分配和释放内存块的速度比其他机制要慢，并且无法直接控制物理存储器的提交和回收。进程和线程都有自己的堆栈，而且大小可以更改。

8) DLL使用：windows中广泛的使用dll来实现模块化，dll的使用一般有静态和动态加载，静态加载一般通过编译器的设置来实现，动态加载通过使用loadlibrary（）和freelibrary（）来实现。

9）结构化异常处理（SEH）：SEH 是 Windows 系统提供的异常处理功能，跟开发工具无关。windows上其他程序中的异常处理一般底层都是转化为SEH来实现。实际上，当你写一条C++ throw语句时，编译器就生成一个对Windows的RaiseException函数的调用。用于throw语句的变量传递给RaiseException作为附加的参数。

四《Windows via c++》之新增

1）64位支持：最新的系统有64的版本，这样的话进程就不再有最大4G的内存限制，但是由于64位系统与以前的32位系统其实是一个codebase，所以基本有所的接口都与以前32位保持椅子，这样的话我们以前的所有的32位的程序只需要从新编译就可以运行在64系统上，需要特别注意的是指针和句柄的从32位到64位的转变。

2）windows vista/2008特有：提供了更加安全的stirng函数，一些内核对象的改变等。

3）可重复使用的代码：大量可在我们日常开发中重复使用的代码和让我们更好的理解进程的源代码processInfo，LockCop等。

五总结

总之，通过阅读《Windows via C++》使我们更好的了解windows系统，更好的在windows进行C++开发！推荐windows上C++开发人员可以一读！

梦在天涯 2008-07-13 10:37 发表评论

windows开发经典图书推荐

梦在天涯 — Thu, 10 Jul 2008 09:19:00 +0800

不能不说是经典啊！我觉的是非常的经典啊！感谢图灵！借首页一用哦！

参考：http://www.cnblogs.com/turingbooks/archive/2008/07/04/1235964.html
更多图灵图书可以看：http://www.cnblogs.com/turingbooks/

购买：http://www.china-pub.com/static/zt_mb/zt_huodong_0808.asp?filename=jsj_tlms_080702

梦在天涯 2008-07-10 09:19 发表评论