久久99热这里只有精品国产,97久久精品国产精品青草,国产精品美女久久久久久2018

鑫龙 — Tue, 13 Jan 2015 12:35:00 GMT

摘要: 1 背景 12 Volatile�Q�易变的 12.1 ��结 23 Volatil... 阅读全文

鑫龙 2015-01-13 20:35 发表评论

函数调用�U�定�Q�_stdcall�Q�_cdecl�Q�_fastcall (�?

鑫龙 — Thu, 27 Dec 2012 03:41:00 GMT

(1) _stdcall调用

　　_stdcall 是Standard Call的羃写，是C++的标准调用方式，也是Pascal�E�序的缺省调用方式，参数采用从右到左的压栈方式，如果是调用类成员的话�Q�最后一个入栈的是this指针。这些堆栈中的参数由被调函数自��n在返回前清空�Q?/div>

使用的指令是 retn X�Q�X表示参数占用的字节数�Q�CPU在ret之后自动弹出X个字节的堆栈�I�间。称��动清栈�?/div>

　　WIN32 Api都采用_stdcall调用方式�Q�这��L��宏定义说明了问题�Q?/div>

　　#define WINAPI _stdcall

　　按C�~�译方式�Q�_stdcall调用�U�定在输出函数名前面加下划线�Q�后面加“@”�W�号和参数的字节敎ͼ�形如_functionname@number�?/div>

(2) _cdecl调用

　　_cdecl是C Declaration[声明]的羃写，表示C/C++语言默认的函数调用方法，也是C/C++的缺省调用方式，所有参�?span style="color: red;">从右到左依次入栈�Q�这些参数由调用者清�?/span>�Q�称为手动清栈。_cedcl�U�定的函数只能被C/C++调用�Q�每一个调用它�?/div>

函数都包含清�I�堆栈的代码�Q�所以��生的可执行文件大��会比调用_stdcall函数的大。被调用函数无需要求调用者传递多��参敎ͼ�调用者传递过多或者过��的参数�Q�甚臛_��全不同的参数都不会��生编译阶�D늚�错误�?/div>

　　�׃��_cdecl调用方式的参数内存栈��p��用者维护，所以变长参数的函数能（也只能）使用�q�种调用�U�定�?/div>

　　�׃��Visual C++默认采用_cdecl 调用方式�Q�所以VC中中调用DLL�Ӟ��用户应��用_stdcall调用�U�定�?/div>

　　按C�~�译方式�Q�_cdecl调用�U�定仅在输出函数名前面加下划�U�，形如_functionname�?/div>

(3) _fastcall调用

　　_fastcall 是编译器指定的快速调用方式。由于大多数的函数参��C��数很��，使用堆栈传递比较费时。因此_fastcall通常规定��前两个�Q�或若干个）参数由寄存器传递，其余参数�q�是通过堆栈传递。不同编译器�~�译的程序规定的�?/div>

存器不同。返回方式和_stdcall相当�?/div>

　　_fastcall调用较快�Q�它通过CPU内部寄存器传递参数�?/div>

(4)PASCAL调用

PASCAL 是Pascal语言的函数调用方式，也可以在C/C++中��用，参数压栈��序与_cdecl和_stdcall相反�?/div>

归纳如下:

调用�U�定入栈参数清理参数入栈��序

----------- -------------- ----------------

cdecl 调用者处�? �?>�?/div>

stdcall 函数自己处理 �?>�?/div>

fastcall 函数自己处理依赖于编译器

pascal 函数自己处理 �?>�?/div>

鑫龙 2012-12-27 11:41 发表评论

左值和叛_��|��转）

鑫龙 — Sun, 16 Dec 2012 07:08:00 GMT

左值右�?/span>

左��|��lvalue�Q�和叛_��|��rvalue�Q�是�~�程中两个非常基本的概念�Q�但是也非常�Ҏ��让�h误解�Q�看了很多文章，自我感觉真正��这个问题讲的很透彻的文章还没有看见�Q�所以自告奋勇来��试一下。如果左值右值的概念不是非常清楚的话�Q�它们迟早会像拦路虎一栯��出来�Q�让你烦心不�Ԍ��像玩电脑游戏的时候每隔一�D�|��间��L��那么几个地雷考验你的耐性，如果一�ơ把所有地��h��就好了。：�Q?/span>

左��|��lvalue�Q�和叛_��|��rvalue�Q�最先来源于�~�译理论�Q�感谢南大小癑֐�的programs�Q�。在C语言中表�C�Z��于赋��D��符两侧的两个��|��左边的就叫左��|��双��的就叫右倹{��比如：

int ii = 5;//ii是左��|��5是右�?/span>

int jj = ii;//jj是左��|��ii是右�?/span>

上面表明�Q�左��D��定可以作为右��g��用，但反之则不然。左值和叛_��的最早区别就在于能否改变。左值是可以变的�Q�右��g��能变。【注1�?/span>

�?/span>1�Q�这一点在C++中已�l?/span>猪羊变色�Q�不再成立。拱猪游戏还是挺好玩的，我还真抓�q�好几次全红心，不过真的好险。：�Q?/span>

在很多文章中提到�Q�在C++中，左值更多的指的是可以定位，��x��地址的��|��而右值没有地址。【注2�?/span>

�?/span>2�Q�这一点仍然不准确�Q�我在程序中生成一个��时右�?/span>std::vector()�Q�你能够说它没有地址吗？��N��它是没有肉体的鬼��或�q�灵�Q�它是有地址的，而且它也是绝对的叛_��{�?/span>

在现�?/span>C++中，现在左值和叛_��基本上已经失去它们原本所��h��的意义，对于左��D��辑ּ��Q�通过具体名字和引用（pointer or reference�Q�来指定一个对象。非左值就是右倹{��我来下一个定义：

左��D��C�程序中必须有一个特定的名字引用到这个倹{�?/span>

叛_��D��C�程序中没有一个特定的名字引用到这个倹{�?/span>

跟它们是否可以改变，是否在栈或堆�Q?/span>stack or heap�Q�中有地址毫无关系�?/span>

1�Q�左�?/span>

在下面的代码中：

int ii = 5;

int const jj = ii;

int a[5];

a[0] = 100;

*(a+3) = 200;

int const& max( int const& a, int const& b ) //call by reference

{

return a > b ? a : b;

}

int& fun(int& a) //call by reference

{

a += 5;

return a;

}

ii�Q?/span>jj�Q?/span>a[0]�Q?/span>*(a+3)�Q�还有函�?/span>max的返回值比�?/span>max(ii, jj)�Q�【注3】函�?/span>fun的返回�?/span>fun(ii)都是左倹{��，它们都是有特定的引用名字的倹{�?/span>ii�Q?/span>jj�Q?/span>a[0]�Q?/span>*(a+3)�Q?/span>max(ii, jj)�Q?/span>fun(ii)分别��是它们的名字�?/span>

�?/span>3�Q�在�q�里有一个不太容易分清楚的盲炏V��那��是有�h会问max(8, 9)到达是左��D��是右��|��C++标准规定帔R��引用�Q?/span>reference to const�Q�可以引用到叛_��|��所�?/span>max(8, 9)��g��应该是右��|��不过不管它是左��|��q�是叛_��|��我们都不能试囑֎�改变它。�ؓ了与前面的概念一��_��我认为它是左��|��不可改变的常量左倹{�?/span>

左值有不能改变的，卌��const所修饰的左��|��比如上面�?/span>jj�Q?/span>max(ii, jj)都是被常量（const�Q�魔咒所��C��的左倹{�?/span>

没有�?/span>const��C��的左值当然是可以改变的，比如下面的代码都是成立的�Q?/span>

ii = 600;

a[0] = 700;

fun(ii) = 800; //OK!

我们的眼睛没有问题，fun(ii) = 800;完全正确�Q�因为它是可以改变的左倹{�?/span>所以我们看STL的源码，��׃��理解std::vector中的重蝲operator[]�q�算�W�的�q�回��gؓ什么要写成引用�Q�因�?/span>operator[]必须�q�回左倹{�?/span>

2�Q�右�?/span>

没有特定名字的值是叛_��{��先看下面的代码�Q?/span>

std::list();

std::string(“It is a rvalue!”);

int fun1() //call by value

{

…

}

int* fun2() //call by reference

{

…

}

其中std::list()�Q?/span>std::string(“It is a rvalue!”)�Q�函�?/span>fun1的返回�?/span>fun1()�Q�函�?/span>fun2的返回�?/span>fun2()都是叛_��|��它们的值都没有特定的名字去引用。也许有��Z��奇怪，fun2()也是叛_��|��最前面�?/span>max(a,b)不是左值吗�Q?/span>

��L��清楚�Q�函�?/span>fun2的返回值是pointer�Q?/span>pointer也是call by value�Q�而函�?/span>max的返回值是reference�Q?/span>reference�?/span>call by reference。所以说C++中引�?/span>reference不仅仅是��Z��方便�Q�它也是一�U�必��R��【注4�?/span>

�?/span>4�Q?/span>Scott Meyer写的�?/span>More Effective C++》的条款1专门讲了pointer�?/span>reference的区别，写的很好�Q��L别的非常清楚�?/span>

fun2()是右��|��?/span> *fun2()却是左��|��p��l�常看到�?/span>*p一��P��所以看C++库代码的时候，会发现重�?/span>operator*的函数返回值是reference�?/span>

当然我还遗漏了一�U�右��|��那就是字面上的（literal�Q��|��比如5�Q?/span>8.23�Q?/span>’a’�{�等理所当然的都是右倹{�?/span>

叛_��最初出现的时候，一个最大的特征��是不可改变。但��p��我们的道��h��准一��P��时代不同了，标准也变化了�Q�以前的三纲五常早已�l�被扔到历史的垃圑֠�里面了�?/span>

C++中有可以改变的右��|��而且�q�个�Ҏ��还非常有用。那��是用户自定义的�c�（class�Q�的构造函数生成的临时对象。比如：

std::vector(9)�Q?/span>std::deque()�Q?#8230;…都是可以改变的右倹{��在Herb Sutter的�?/span>More Exceptional C++》中的条��?/span>7�?/span>page51��|��q�样几行代码�Q?/span>

// Example 7-2(b): The right way to shrink-to-fit a vector.

vector c( 10000 );

// ...now c.capacity() >= 10000...

// erase all but the first 10 elements

c.erase( c.begin()+10, c.end() );

// the following line does shrink c's

// internal buffer to fit (or close)

vector( c ).swap( c );

// ...now c.capacity() == c.size(), or

// perhaps a little more than c.size()

认真看几遍，你会发现�?/span>vector的大��增大到一定程度，你又用不着�q�么多空间的时候，你会惛_��法把它收�~�到最合适的大小�Q�但利用别的办法比如调用成员函数reserve()都无法办刎ͼ��q�个时候就必须利用叛_��可以改变这个性质了�?/span>

vector( c ).swap( c );�q�行代码��是点睛之处�?/span>

首先使用复制构造函数生成��时右�?/span>vector( c )�Q�这个右值正好是合适大��，然后�?/span>c交换【注5】，c��变成合适大��了�Q�最后在整个表达式结束的时候，�q�个临时叛_��析构归�q�内存空间。真是绅士一般的优雅�Q?/span>

�?/span>5�Q�这个时候这个��时右值就发生了改变�?/span>

如果�q�不理解�Q�可以看看书�Q�或者直接看库的源代码�?/span>

至于��Z��么会�q�样�Q�我思考了一下，我想是这��L��Q�我们看�c�（class�Q�的数据布置�l�构�Q�会发现它的每一个数据成员都是有名字的，我想�~�译器在�~�译的过�E�中�Q�都会生成一个外部不所知的对这个��时对象右值的名字引用�Q�但需要改变这个��时对象的时候，�q�个名字��q��上了。比如：

class Point

{

public: //�U��a��Z��方便�Q�我把数据成员公开�Q�现实中��量不要�q�样�?/span>

int x, y ,z;

……//其他各种成员函数

};

我们现在��可以改变右��|��用到了匿名的引用名字�?/span>

Point().x = 6;//改变了右�?/span>

Point().y = 6;//同意改变了右��|��不过注意�Q�这个右��D��上面的不是同一个�?/span>

�ȝ��

左值和叛_��的真正区别我想��是�q�些了，左��D��C�有特定的名字引用，而右值没有特定的名字引用。当然我仍然会有疏忽�Q�希望大家能够提醒我�Q�指正我的不��?/span>

前两天看Herb Sutter从邮件中寄来的新文章�Q�我订阅他的新文章邮仉��知�Q�，一��是�?/span>Tuple数据�l�构的，没有什么新意，以前好像看过�Q�还有一��名字是�Q�（Mostly�Q?/span>Private,地址�?/span>http://www.cuj.com/documents/s=8273/cujcexp2107sutter/ 内容本��n�q�不深，但看完文章，发现随处可见C++的�L诡云�Ԍ��又会对什么叫袖里乑֝��Q�滴水藏��多一份感性认识�?/span>

在下一��文章我想从不同于一般的角度�Q�从自己的经历谈谈在校毕业生�?/span>IT行业怎样扑ַ�作，我想会让所有读者都有一些思考，不仅仅是求职者。题目我已经惛_��了，��叫《扮虎吃猪》，不过现在我有一些别的事情要忙，所以可能会让大家等几天�?/span>

转蝲��h��明来源，谢谢�Q?/span>

吴桐写于2003.6.20

最�q�修�?/span>2003.6.21

转自�Q?/span> http://blog.csdn.net/csdnji/article/details/169200

鑫龙 2012-12-16 15:08 发表评论

拯��构造函数和赋值操作函数的参数��Z��么是const�?amp;?!

鑫龙 — Sun, 16 Dec 2012 06:52:00 GMT

习惯了这样写�Q�但有时候会反问下自�׃ؓ什么要const�?amp;?
1.��Z��么要&?
�{�：&是必��ȝ��?br />如果它不是引用，在传递参数时�Q�会产生一个局部变量做参数�Q�而这个局部变量的构造又要调copy构造函��C��?....那就子子孙孙无穷匮了....
但如果是引用�Q�在传递参数时候，局部变量只需要绑定原变量�Q�而不需要再一�ơ调用copy构造函数�?br />
2.��Z��么要const?
�{�：const不是必须的�?br />

构造函数是用引用方式传递复制对象，引用方式传递的是地址�Q�因此在构造函数内对该引用的修改会影响源对象。而你在用对象a1构造a2�Ӟ��自然不希望复制构造函��C��改变a1的内容，因此要防止复制构造函数内部修改该引用�Q�所以一般用const声明。加不加const�q�是需要看copy构造的行�ؓ�Q�比如std::auto_ptr的构造函敎ͼ����没有const,因�ؓ它要获得原有对象指针的拥有权�?/pre>

鑫龙 2012-12-16 14:52 发表评论

C++模板元编�E?入门��?(�?

鑫龙 — Sat, 01 Dec 2012 12:01:00 GMT

C++模板元编�E?入门��?/a>

最�q�一直在看STL和Boost�Q�源码里边好多涉及到模板元编�E�技术，��单了解一下，备忘�Q�Boost Python中的涉及模板元的部分重点��x��一下）�?/p>

范例引入

// ��L��?/span>
template<int N>
struct Fib
{
    enum { Result = Fib<N-1>::Result + Fib<N-2>::Result };
};

// 完全特化�?/span>
template <>
struct Fib<1>
{
    enum { Result = 1 };
};

// 完全特化�?/span>
template <>
struct Fib<0>
{
    enum { Result = 0 };
};

int main()
{
    int i = Fib<10>::Result;
    // std::cout << i << std::endl;
}

主要思想

利用模板特化机制实现�~�译期条仉��择�l�构�Q�利用递归模板实现�~�译期��@环结构，模板元程序则��q��译器在编译期解释执行�?/p>

优劣及适用情况

通过��计��从�q�行期�{�U�至�~�译期，在结果程序启动之前做��可能多的工作，最�l�获得速度更快的程序。也��是说模板元�~�程的优势在于：

　　1.以编译耗时��Z��h��来卓��的�q�行期性能�Q�一般用于�ؓ性能要求严格的数��D��换取更高的性能�Q�。通常来说�Q�一个有意义的程序的�q�行�ơ数�Q�或服役旉��Q��L��q�远��过�~�译�ơ数�Q�或�~�译旉��Q��?/p>

　　2.提供�~�译期类型计��，通常�q�才是模板元�~�程大放异彩的地斏V�?/p>

模板元编�E�技术�ƈ非都是优点：

　　1.代码可读性差�Q�以�c�L��板的方式描述��法也许有点抽象�?/p>

　　2.调试困难�Q�元�E�序执行于编译期�Q�没有用于单步跟�t�元�E�序执行的调试器�Q�用于设�|�断炏V��察看数据等�Q�。程序员可做的只能是�{�待�~�译�q�程��p�|�Q�然后�h工破译编译器倾泻到屏�q�上的错误信息�?/p>

　　3.�~�译旉��长，通常带有模板元程序的�E�序生成的代码尺寸要比普通程序的大，

　　4.可移植性较差，对于模板元编�E��用的高��模板�Ҏ��，不同的编译器的支持度不同�?/p>

�ȝ��Q?/p>

模板元编�E�技术不适用普通程序员的日常应用，它常�怼�做�ؓ�c�d��开发的提供技术支持，为常规模板代码的内核的关键算法实现更好的性能或者编译期�c�d��计算。模板元�E�序几乎��L��应该与常规代码结合��用被��装在一个程序库的内部。对于库的用��h��_��它应该是透明的�?/p>

工程应用实例

1. Blitz++�Q�由于模板元�~�程最先是因�ؓ数��D��而被发现的，因此早期的研�I�工作主要集中于数��D��方面，Blitz++库利用模板将�q�行期计��{�U�至�~�译期的库，主要提供了对向量、矩�늭��q�行处理的线性代数计��?/p>

2.Loki�Q�将模板元编�E�在�c�d��计算斚w��的威力应用于设计模式领域�Q�利用元�~�程�Q�以及其他一些重要的设计技术）实现了一些常见的设计模式之泛型版本。Loki库中的Abstract Factory泛型模式卛_��助于这�U�机制实现在不损��q��型安全性的前提下降低对�c�d��的静态依赖性�?/p>

3.Boost�Q�元�~�程库目前主要包含MPL、Type Traits和Static Assert�{�库�?Static Assert和Type Traits用作MPL的基��。Boost Type Traits库包含一�p�d��traits�c�，用于萃取C++�c�d��特征。另外还包含了一些�{换traits�Q�例如移除一个类型的const修饰�W�等�Q�。Boost Static Assert库用于编译期断言�Q�如果评估的表达式编译时计算�l�果为true�Q�则代码可以通过�~�译�Q�否则编译报错�?/p>

技术细�?/strong>

模板元编�E��用静态C++语言成分�Q�编�E�风格类��g��函数式编�E�，在模板元�~�程中，主要操作整型�Q�包括布��类型、字�W�类型、整数类型）帔R��和类型，不可以��用变量、赋��D��句和�q�代�l�构�{�。被操纵的实体也�U�Cؓ元数据（Metadata�Q�，所有元数据均可作�ؓ模板参数�?/p>

�׃��在模板元�~�程中不可以使用变量�Q�我们只能��用typedef名字和整型常量。它们分别采用一个类型和整数��D��行初始化�Q�之后不能再赋予新的�c�d��或数倹{��如果需要新的类型或数��|��必须引入新的typedef名字或常量�?/p>

其它范例

// 仅声�?/span>
struct Nil;

// ��L��?/span>
template <typename T>
struct IsPointer
{
    enum { Result = false };
    typedef Nil ValueType;
};

// 局部特�?/span>
template <typename T>
struct IsPointer<T*>
{
    enum { Result = true };
    typedef T ValueType;
};

// �C�Z��
int main()
{
    cout << IsPointer<int*>::Result << endl;
    cout << IsPointer<int>::Result << endl;
    IsPointer<int*>::ValueType i = 1;
    //IsPointer::ValueType j = 1;
    // 错误�Q��用未定义的类型Nil
}

//��L��?/span>
template<bool>
struct StaticAssert;

// 完全特化
template<>
struct StaticAssert<true>
{};

// 辅助�?/span>
#define STATIC_ASSERT(exp)\
{ StaticAssert<((exp) != 0)> StaticAssertFailed; }

int main()
{
STATIC_ASSERT(0>1);
}

References�Q?/strong>
http://club.topsage.com/thread-421469-1-1.html
http://wenku.baidu.com/view/c769720df78a6529647d539d.html
Blitz++�Q?nbsp;http://www.oonumerics.org/blitz .
Loki �Q?a target="_blank" style="box-sizing: border-box; color: #3468a4;">http://sourceforge.net/projects/loki-lib
Boost�Q?a style="box-sizing: border-box; color: #3468a4;">http://www.boost.org/

鑫龙 2012-12-01 20:01 发表评论

Traits 技�?--- 模板元编�E?(�?

鑫龙 — Sat, 01 Dec 2012 11:57:00 GMT

什么是traits�Q��ؓ什么�h们把它认为是C++ Generic Programming的重要技术？

��z�地��_��traits如此重要�Q�是因�ؓ此项技术允许系�l�在�~�译时根据类型作一些决断，��好像在�q�行时根据值来做出��x��一栗��更�q�一步，此技术遵�?#8220;另增一个间接层”的谚语，解决了不��Y件工�E�问题，traits使您能根据其产生的背�?context) 来做出抉择。这��h��l�的代码��变得清晰易读，�Ҏ��l�护。如果你正确�q�用了traits技术，你就能在不付��Z�Q何性能和安全代��L��同时得到�q�些好处�Q�或者能够契合其他解��x��案上的需求�?br />
先�D个浅显易懂的例子来说明traits的用法：
//首先假如有以下一个泛型的�q�代器类�Q�其中类型参�?nbsp;T ��P代器所指向的类型：
template
class myIterator
{

};
那么当��用myIterator�Ӟ��怎样才能知道它所指向元素的类型呢�Q�一�U�解��x��案是��个类加入一个内嵌类型：
template
class myIterator
{
typedef T value_type;

};
当��用myIterator�Ӟ��可以通过myIterator::value_type来获得相应的myIterator所指向的类型。下面�D例��用：
template
typename myIterator::value_type func(myIterator i)
{

}
�q�里定义了一个函数func�Q�返回值类型�ؓ参数i所指的�c�d��Q�也��是模板参数T�Q�那么�ؓ什么不直接使用模板参数T�Q�而要�l�着圈去使用那个value_type呢？所以我们返回来�Q�当修改func函数�Ӟ��它能够适应所有类型的�q�代器，不是更好吗？如下所�C�：
template  //�q�里的I可以是�Q意类型的�q�代�?/span>
typename I::value_type func(I i)
{

}
现在�Q��Q意定义了value_type内嵌�c�d��的�P代器都可以做为func的参��C��Q��ƈ且func的返回值的�c�d��与相应�q�代器所指的元素的类型一致。至此一切问题似乎都已解冻I��q�且��g��q�没有��用�Q何特�D�的技术�?br /> 然而当考虑��C��下情冉|��Q�新的问题便昄��出来了：原生指针也完全可以做��P代器来��用，然而显然没有办法�ؓ原生指针��d��一个value_type的内嵌类型，如此一来func()函数��׃��能适用原生指针了，�q�不能不说是一大缺憾。那么有什么办法可以解册��个问题呢�Q�此时不��想��C��用Traits萃取�c�d��信息。可以不直接使用myIterator的value_type�Q�而是通过Traits�c�L��把这个信息提取出来：(不同的类型，可以有不同的提取方式)
template
class Traits
{
typedef typename T::value_type value_type;
};
�q�样以后��可以通过Traits::value_type来提取出myIterator中的value_type�Q�于是func函数改写成：
template  //�q�里的I可以是�Q意类型的�q�代�?/span>
typename Traits::value_type Foo(I i)
{

}
然而，即�ɘq�样�Q�那个原生指针的问题仍然没有解决�Q�因为Trait�c�还是没办法获得原生指针的相关信息。于是不妨将Traits偏特�?partial specialization)�Q?通过特化、重载特化等手段产出不同的提取方�?
template
class Traits //注意 �q�里针对原生指针�q�行了偏特化
{
typedef typename T value_type;
};
通过上面�q�个Traits的偏特化版本�Q�一个T*�c�d��的指针所指向的元素的�c�d��为T。如此一来，我们func函数��完全可以适用于原生指针了。比如：
int * p;
.
int i = func(p);
Traits会自动推导出p所指元素的�c�d��为int�Q�从而func正确�q�回�?/div>
-----------------------------------------------------------------------------------------------------------------------------------------------------------
现在再看一个更加一般的例子——smart pointers�?��指针)
假设你正在设计一个SmartPtr模板�c�，对于一个smart pointer 来说�Q�它的最大的用处是可以自动管理内存问题，同时在其他方面又像一个常规指针。但是有些C++的Smart pointer实现技术却非常令�h难以理解。这一�D�酷的事实带来了一个重要实�늻�验：你最好尽一切可能一��x��逸，写出一个出色的、具有工业强度的 smart pointer来满��你所有的需求。此外，你通常不能修改一个类来适应你的smart pointer�Q�所以你的SmartPtr一定要��_��灉|��?/div>
有不��类层次使用引用计数(reference counting)以及相应的函数管理对象的生存期。然而，�q�没有reference counting的标准实现方法，每一个C++库的供应商在实现的语法和/或语义上都有所不同。例如，在你的应用程序中有这样两个interfaces�Q?br />�W�一�U�智能指�?-大部分的�c�d��C��RefCounted接口:
class RefCounted
{
public:
virtual void IncRef() = 0;
virtual bool DecRef() = 0;
// if you DecRef() to zero references, the object is destroyed
// automatically and DecRef() returns true
virtual ~RefCounted() {}
};
�W�二�U�智能指�?-�W�三�Ҏ��供的Widget�c�M��用不同的接口�Q?/div>
class Widget
{
public:
void AddReference();
int RemoveReference();
// returns the remaining number of references; it's the client's
// responsibility to destroy the object

};
不过你�ƈ不想�l�护两个smart pointer�c�，你想让两�U�类�׃�n一个SmartPtr。一个基于traits的解��x��案把两种不同的接口用语法和语义上�l�一的接口包装�v来，建立针对普通类的通用模板�Q�而针对Widget建立一个特�D�化版本�Q�如下：
template <class T>
class RefCountingTraits
{
static void Refer(T* p)
{
p->IncRef(); // assume RefCounted interface
}
static void Unrefer(T* p)
{
p->DecRef(); //assume RefCounted interface
}
};
template<>
class RefCountingTraits
{
static void Refer(Widget* p)
{
p->AddReference(); //use Widget interface
}
static void Unrefer(Widget* p)
{
//use Widget interface
If (p->RemoveReference() == 0)
delete p;
}
};
在SmartPtr里，我们像这样��用RefCountingTraits:
template <class T>
class SmartPtr
{
private:
typedef RefCountingTraits RCTraits;
T* pointee_;
public:

~SmartPtr()
{
RCTraits::Unrefer(pointee_);
}
};
当然在上面的例子里，你可能会争论说你可以直接�Ҏ��化Widget�cȝ��SmartPtr的构造与析构函数。你可以使用把模板特�D�化技术用�?SmartPtr本��n�Q�而不是用在traits上头�Q�这栯��可以消除额外的类。尽��对�q�个问题来说�q�种��x��没错�Q�但�q�是�׃��些你需要注意的�~�陷�Q?/div>
�q�么�q�缺乏可扩展性。如果给SmartPtr再增加一个模板参敎ͼ�你不能特�D�化�q�样一个SmartPtr�Q�其中模板参数T是Widget�Q�而U可以为其他�Q何类型�?/li>
最�l�代码不那么清晰。Trait有一个名字，而且把相关的东西很好的组�l��v来，因此使用traits的代码更加容易理解。相比之下，用直接特�D�化SmartPtr成员函数的代码，看上��L��招黑客的喜欢�?/li>
用��承机制的解决�Ҏ��Q�就��本�w�完��无瑕，也至��存在上�q�的�~�陷。解册��样一个变体问题，使用�l�承实在是太�W�重了。此外，通常用以取代�l�承�Ҏ��的另一�U�经典机�?#8212;—containment�Q�用在这里也昑־�画蛇添��Q�繁琐不堪。相反，traits�Ҏ��q�净利落�Q�简明有效，物合其用�Q�恰到好处�?/div>
Traits的一个重要的应用�?#8220;interface glue”�Q�接口胶合剂�Q�，通用的、可适应性极强的适配子。如果不同的�c�d��于一个给定的概念有着不同的实玎ͼ�traits可以把这些实现再�l�织�l�一成一个公��q��接口。对于一个给定类型提供多�U�TRAITS�Q�现在，我们假设所有的人都很喜�Ƣ你的SmartPtr模板�c�，直到有一天，在你的多�U�程应用�E�序里开始现了神�U�的bug。你发现�|�魁��R��是Widget�Q�它的引用计数函数�ƈ不是�U�程安全的。现在你不得不亲自实现Widget:: AddReference和Widget::RemoveReference�Q�最合理的位�|�应该是在RefCountingTraits中，打上个补丁吧�Q?/div>
// Example 7: Patching Widget's traits for thread safety
template <>
class RefCountingTraits
{
static void Refer(Widget* p)
{
Sentry s(lock_); // serialize access
p->AddReference();
}
static void Unrefer(Widget* p)
{
Sentry s(lock_); // serialize access
if (p->RemoveReference() == 0)
delete p;
}
private:
static Lock lock_;
};
不幸的是�Q�虽然你重新�~�译、测试之后正��运行，但是�E�序慢得像蜗牛。仔�l�分析之后发玎ͼ�你刚才的所作所为往�E�序里塞了一个糟�p�的瓉��。实际上只有��数几个Widget是需要能够被好几个线�E�访问的�Q�余下的�l�大多数Widget都是只被一个线�E�访问的。你要做的是告诉�~�译器按你的需求分别��用多�U�程traits和单�U�程traits�q�两个不同版本。你的代码主要��用单�U�程traits�?/div>
如何告诉�~�译器��用哪个traits�Q�一�U�方法是把traits作�ؓ另一个模板参��C��l�SmartPtr。缺省情况下传递老式的traits模板�Q�而用特定的类型实例化特定的模�ѝ�?/div>
template <class T, class RCTraits = RefCountingTraits >
class SmartPtr
{

};
你对单线�E�版的RefCountingTraits不做改动�Q�而把多线�E�版攑֜�一个单独的�c�M��Q?/div>
class MtRefCountingTraits
{
static void Refer(Widget* p)
{
Sentry s(lock_); // serialize access
p->AddReference();
}
static void Unrefer(Widget* p)
{
Sentry s(lock_); // serialize access
if (p->RemoveReference() == 0)
delete p;
}
private:
static Lock lock_;
};
现在你可��SmartPtr用于单线�E�目的，��SmartPtr用于多线�E�目的�?/div>
最后，以SGI STL中的__type_traits�l�束本篇讨论�Q�在SGI 实现版的STL中，��Z��获取高效率，提供了__type_traits�Q�用来提取类的信息，比如�c�L��否拥有trival的构造、析构、拷贝、赋值操作，然后跟据具体的信息，��可提供最有效率的操作。以下摘录cygwin的gcc3.3源码�Q�有改动�Q�在中�?/div>
struct __true_type {};
struct __false_type {};
template <class _Tp>
struct __type_traits
{
typedef __true_type    this_dummy_member_must_be_first;
typedef __false_type    has_trivial_default_constructor;
typedef __false_type    has_trivial_copy_constructor;
typedef __false_type    has_trivial_assignment_operator;
typedef __false_type    has_trivial_destructor;
typedef __false_type    is_POD_type;
};
对于普通类来讲�Q��ؓ了安全�v见，都认为它们拥有non-trival的构造、析构、拷贝、赋值函敎ͼ�POD是指plain old data。接下来对C++的原生类型（bool�Q�int�Q?double之类�Q�定义了昑ּ�的特化实玎ͼ�以double��Z��Q?/div>
template<>
struct __type_traits<long double> {
typedef __true_type    has_trivial_default_constructor;
typedef __true_type    has_trivial_copy_constructor;
typedef __true_type    has_trivial_assignment_operator;
typedef __true_type    has_trivial_destructor;
typedef __true_type    is_POD_type;
};
�q�有�Q�对所有的原生指针来讲�Q�它们的构造、析构等操作也是trival的，因此有：
template <class _Tp>
struct __type_traits<_Tp*> {
typedef __true_type    has_trivial_default_constructor;
typedef __true_type    has_trivial_copy_constructor;
typedef __true_type    has_trivial_assignment_operator;
typedef __true_type    has_trivial_destructor;
typedef __true_type    is_POD_type;
};
��?lt;stl_algobase.h>中copy的部分代码来说明对__type_traits的应用�?/div>
template
inline _Tp* __copy_trivial(const _Tp* __first, const _Tp* __last, _Tp* __result)
{
memmove(__result, __first, sizeof(_Tp) * (__last - __first));
return __result + (__last - __first);
}
template
inline _Tp* __copy_aux (_Tp* __first, _Tp* __last, _Tp* __result, __true_type)
{ return __copy_trivial(__first, __last, __result); }
template
inline _Tp* __copy_aux (_Tp* __first, _Tp* __last, _Tp* __result, __false_type)
{ 另外处理�Q�}
template inline
_OutputIter copy (_InputIter __first, _InputIter __last, _OutputIter __result)
{
typedef typename iterator_traits<_InputIter>::value_type _ValueType;
typedef typename __type_traits<_ValueType>::has_trivial_assignment_operator _Trivial;
return __copy_aux(__first, __last, __result, _Trivial());
}
Copy 函数利用__type_traits判断当前的value_type是否有trival的赋值操作，如果是，则��生类__true_type的实例，�~�译旉��择__copy_trivial函数�q�行memmove�Q�效率最高。如果是non-trival的赋值操作，则另作处理，效率自然低些。__true_type和__false_type之所以是�c�，��因为C++的函数重载是�Ҏ��c�d��信息来的�Q�不能依据参数值来判别。��用SGI STL�Ӟ��可以��q��c�d��义__type_traits昑ּ�特化版本�Q�以求达到高效率�?/div>
本文来自CSDN博客�Q��{载请标明出处�Q�http://blog.csdn.net/budTang/archive/2008/05/06/2397013.aspx

鑫龙 2012-12-01 19:57 发表评论

C++�c�d��转换�ȝ��(�?

鑫龙 — Sun, 25 Nov 2012 09:33:00 GMT

C风格的强制类型�{�?Type Cast)很简单，不管什么类型的转换�l�统是：
TYPE b = (TYPE)a�?br />C++风格的类型�{换提供了4�U�类型�{换操作符来应对不同场合的应用�?/p>
const_cast�Q�字面上理解��是去const属性�?br />static_cast�Q�命名上理解是静态类型�{换。如int转换成char�?br />dynamic_cast�Q�命名上理解是动态类型�{换。如子类和父�c�M��间的多态类型�{换�?br />reinterpret_cast�Q�仅仅重新解释类型，但没有进行二�q�制的�{换�?br />4�U�类型�{换的格式�Q�如�Q�TYPE B = static_cast(TYPE)(a)�?/p>
const_cast
��L��c�d��的const或volatile属性�?/p>
1 struct SA {
2 int i;
3 };
4 const SA ra;
5 //ra.i = 10; //直接修改const�c�d��Q�编译错�?/span>
6 SA &rb = const_cast<SA&>(ra);
7 rb.i = 10;
static_cast
�c�M��于C风格的强制�{换。无条�g转换�Q�静态类型�{换。用于：
1. 基类和子�c�M��间�{换：其中子类指针转换成父�c�L��针是安全的；但父�c�L��针�{换成子类指针是不安全的�?基类和子�c�M��间的动态类型�{换徏议用dynamic_cast)
2. 基本数据�c�d��转换。enum, struct, int, char, float�{�。static_cast不能�q�行无关�c�d��Q�如非基�c�d��子类�Q�指针之间的转换�?br />3. 把空指针转换成目标类型的�I�指针�?br />4. 把�Q何类型的表达式�{换成void�c�d��?br />5. static_cast不能��L��c�d��的const、volitale属�?用const_cast)�?/p>
1 int n = 6;
2 double d = static_cast<double>(n); // 基本�c�d��转换
3 int *pn = &n;
4 double *d = static_cast<double *>(&n) //无关�c�d��指针转换�Q�编译错�?/span>
5 void *p = static_cast<void *>(pn); //��L��c�d��转换成void�c�d��
dynamic_cast
有条件�{换，动态类型�{换，�q�行时类型安全检�?转换��p�|�q�回NULL)�Q?br />1. 安全的基�c�d��子类之间转换�?br />2. 必须要有虚函数�?br />3. 相同基类不同子类之间的交叉�{换。但�l�果是NULL�?/p>
1 class BaseClass {
2 public:
3 int m_iNum;
4 virtual void foo(){}; //基类必须有虚函数。保持多台特性才能��用dynamic_cast
5 };
6
7 class DerivedClass: public BaseClass {
8 public:
9 char *m_szName[100];
10 void bar(){};
11 };
12
13 BaseClass* pb = new DerivedClass();
14 DerivedClass *pd1 = static_cast<DerivedClass *>(pb); //子类->父类�Q�静态类型�{换，正确但不推荐
15 DerivedClass *pd2 = dynamic_cast<DerivedClass *>(pb); //子类->父类�Q�动态类型�{换，正确
16
17 BaseClass* pb2 = new BaseClass();
18 DerivedClass *pd21 = static_cast<DerivedClass *>(pb2); //父类->子类�Q�静态类型�{换，危险�Q�访问子�c�m_szName成员��界
19 DerivedClass *pd22 = dynamic_cast<DerivedClass *>(pb2); //父类->子类�Q�动态类型�{换，安全的。结果是NULL
reinterpret_cast
仅仅重新解释�c�d��Q�但没有�q�行二进制的转换�Q?br />1. 转换的类型必��L��一个指针、引用、算术类型、函数指针或者成员指针�?br />2. 在比特位�U�别上进行�{换。它可以把一个指针�{换成一个整敎ͼ�也可以把一个整数�{换成一个指针（先把一个指针�{换成一个整敎ͼ�在把该整数�{换成原类型的指针�Q�还可以得到原先的指针��|��。但不能��非32bit的实例�{成指针�?br />3. 最普通的用途就是在函数指针�c�d��之间�q�行转换�?br />4. 很难保证�U�L��性�?/p>
1 int doSomething(){return 0;};
2 typedef void(*FuncPtr)(); //FuncPtr is 一个指向函数的指针�Q�该函数没有参数�Q�返回值类型�ؓ void
3 FuncPtr funcPtrArray[10]; //10个FuncPtrs指针的数�l?让我们假设你希望�Q�因为某些莫名其妙的原因�Q�把一个指向下面函数的指针存入funcPtrArray数组�Q?/span>
4
5 funcPtrArray[0] = &doSomething;// �~�译错误�Q�类型不匚w��Q�reinterpret_cast可以让编译器以你的方法去看待它们�Q�funcPtrArray
6 funcPtrArray[0] = reinterpret_cast<FuncPtr>(&doSomething); //不同函数指针�c�d��之间�q�行转换
�ȝ��
去const属性用const_cast�?br />基本�c�d��转换用static_cast�?br />多态类之间的类型�{换用daynamic_cast�?br />不同�c�d��的指针类型�{换用reinterpret_cast�?/p>

鑫龙 2012-11-25 17:33 发表评论

c++ cout 格式化输�?�?

鑫龙 — Mon, 19 Nov 2012 06:42:00 GMT

cout 格式化输�?/a>

��?cout �?flag 保存到变�?/strong>, 以便修改后的恢复
ostream::fmtflags old = cout.flag() ; // 无参��返回当�?flag �?/span> cout.flag(old) ; // 恢复到原先保存的�?/span>
复制代码

��?bool ��g�� literals 输出
cout <<"numeric : " <<true <<" or " <<false <<endl ; // 1 or 0 cout <<"literals : " <<boolalpha <<true <<" or " <<false <<endl ; // true or false cout <<"literals : " <<boolalpha <<0 <<endl ; // 0 原因: 0 在cout中不�{��h�?false
复制代码
一旦我们��?boolalpha ��改�?cout �?bool 值的输出格式. 此后�?cout 都会��?bool 输出�?literals.

��?bool ��g�� numeric 输出
cout <<"numeric : " <<noboolalpha <<true <<" or " <<false <<endl ;// 1 or 0
从此以后, cout �?bool 值的输出��恢�?numeric 格式

指定 Integral Values �?Base
const int ival = 17 ; // 'ival' is constant, so value never change cout <<"oct : " <<oct <<ival <<endl ; // 21 : 8 �q�制 cout <<"dec : " <<dec <<ival <<endl ; // 17 : 10 �q�制 cout <<"hex : " <<hex <<ival <<endl ; // 11 : 16 �q�制 cout <<"hex : " <<hex <<17.01 <<endl ; // 17.01 : 不受影响
复制代码
�?boolalpha 一�? oct, dec, hex 也是 persistent. 一旦改�? ��媄响后�l�的输出格式.

昄��表明 Integer Values �?Base
cout <<showbase ; // Show base when printing integral values cout <<"oct : " <<oct <<ival <<endl ; // 21 : 8 �q�制 cout <<"dec : " <<dec <<ival <<endl ; // 017 : 10 �q�制 cout <<"hex : " <<hex <<ival <<endl ; // 0x11 : 16 �q�制 cout <<"hex : " <<hex <<17.01 <<endl ; // 17.01 : 不受影响 cout <<noshowbase ; // Reset state of the stream
复制代码
若想改变16�q�制字母的大��?/strong>, 可以�l�合 uppercase/nouppercase
cout <<showbase <<uppercase ; cout <<"hex : " <<hex <<15 <<endl ; // 0XF 大写形式 cout <<nouppercase ; cout <<"hex : " <<hex <<15 <<endl ; // 0xf ��写形式
复制代码
showbase �?noshowbase 的作用周期也�?persistent

对于 float/double �? 有三�U�格式化控制
一: 输出�_�ֺ� precision : by default is 6 pricision
控制了至多一�׃��输出多少个数�?
当要输出的数字多余指定的值时, ��发�?四舍五入(rounded);
当要输出的数字少于指定的值时, 则实际输出的数字个数��少于指定�?
// cout.pricision(4) ; // �{��h�?cout < cout <<setprecision(4) <<12.345678 <<endl ; // 12.35 rounded! cout <<setprecision(10) <<12.345678 <<endl ; // 12.345678 其实内部发生�?rounded, 而结果正好进�? 与原值相�?/span> cout <<cout.precision() <<endl ; // 输出当前�_�ֺ�
复制代码
�? 表现形式 notation : 'very large and very small values are printed using scientific notation. other values use fixed decimal.'
notation 控制了输出的形式 : �U�学计数�?scientific) �?定点��数(fixed)
float f = 101 / 6.0 ; cout <<fixed <<f <<endl ; // 16.83334 : ��数点后�?�?/span> cout <<scientific <<f <<endl ; // 1.683333e+001 : ��数点后�?�?/span>
复制代码
  恢复到初始状�?br />
cout.unsetf(ostream::floatfield) ; // Retrieve to default handling for notation cout <<f <<endl ; // 16.8333 : 所有数字共6�?/span>
复制代码
�? 输出十进制��Q�?/strong> 'By default, when the fractional part of a floating-point value is 0, the decimal point is not displayed. The showpoint manipulator forces the decimal point ot be printed.'
cout <<10.0 <<endl ; // 10 cout <<showpoint <<10.0 <<endl ; // 10.0000 cout <<noshowpoint <<endl ; // Revert to default handling of decimal
复制代码

输出填充 Padding the Output
setw to specify the minimum space for the next numeric or string value.
cout <<setw(10) <<12.3 <<endl ; // ______12.3 cout <<setw(10) <<12 <<3 <<endl ; // ________123 cout <<setw(3) <<12.345 <<endl ; // If the total output is more than 3, it can be extended
复制代码

left to left-justify the output.
cout <<left ; // left-justify cout <<setw(5) <<12 <<setw(5) <<34 <<endl ; // 12___34___
复制代码

right to right-justify the output. Output is right-justified bu default.
cout <<right ; // By default cout <<setw(5) <<12 <<setw(5) <<34 <<endl ; // 12___34___
复制代码

internal controls placement of the sign on negative value. internal left-justifies the sign and right-justifies the value, padding any intervening space with blanks.(if setfill not set)
cout <<internal ; // By default cout <<setw(5) <<-12 <<endl ; // 12___34___
复制代码

   setfill lets us specify an alternative character to use when padding the output. By default, the value is a space.
cout <<setfill('*') ; // By default cout <<setw(5) <<12 <<endl ; // 12___34___
复制代码

Header Files
Manipulators Defined in <iomanip>
setfill(char ch) Fill whitespace with 'ch' setprecision(int n) Set floating-point precision to 'n' setw(int w) Read or write value to 'w' characters setbase(int b) Output integers in base 'b'(only 'b' is 8/10/16 could the function work)
复制代码

鑫龙 2012-11-19 14:42 发表评论

c++内存泄露机制(�?

鑫龙 — Tue, 06 Nov 2012 13:04:00 GMT
对于一个c/c++�E�序员来��_��内存泄漏是一个常见的也是令�h头疼的问题。已�l�有许多技术被研究出来以应对这个问题，比如 Smart Pointer�Q�Garbage Collection�{�。Smart Pointer技术比较成熟，STL中已�l�包含支持Smart Pointer的class�Q�但是它的��用似乎�ƈ不广泛，而且它也不能解决所有的问题�Q�Garbage Collection技术在Java中已�l�比较成熟，但是在c/c++领域的发展�ƈ不顺畅，虽然很早��有人思考在C++中也加入GC的支持。现实世界就是这��L��Q�作��Z��个c/c++�E�序员，内存泄漏是你心中永远的痛。不�q�好在现在有许多工具能够帮助我们验证内存泄漏的存在，扑և�发生问题的代码�?/span>

　　内存泄漏的定�?/strong>

　　一般我们常说的内存泄漏是指堆内存的泄漏。堆内存是指�E�序从堆中分配的�Q�大��Q意的�Q�内存块的大��可以在�E�序�q�行期决定）�Q��用完后必��L��C�释攄��?存。应用程序一般��用malloc�Q�realloc�Q�new�{�函��C��堆中分配��C��块内存，使用完后�Q�程序必��负责相应的调用free或delete释放�?内存块，否则�Q�这块内存就不能被再�ơ��用，我们��p��q�块内存泄漏了。以下这�D�小�E�序演示了堆内存发生泄漏的情形：

void MyFunction(int nSize)
{
　char* p= new char[nSize];
　if( !GetStringFrom( p, nSize ) ){
　　MessageBox(“Error”);
　　return;
　}
　…//using the string pointed by p;
　delete p;
}

　　例一

　　当函数GetStringFrom()�q�回零的时候，指针p指向的内存就不会被释放。这是一�U�常见的发生内存泄漏的情形。程序在入口处分配内存，在出口处释放内存�Q�但是c函数可以在�Q何地斚w��出，所以一旦有某个出口处没有释攑ֺ�该释攄��内存�Q�就会发生内存泄漏�?/span>

　　�q�义的说�Q�内存泄漏不仅仅包含堆内存的泄漏�Q�还包含�pȝ��资源的泄�?resource leak)�Q�比如核心态HANDLE�Q�GDI Object�Q�SOCKET�Q?Interface�{�，从根本上说这些由操作�pȝ��分配的对象也消耗内存，如果�q�些对象发生泄漏最�l�也会导致内存的泄漏。而且�Q�某些对象消耗的是核心态内存，�q�些对象严重泄漏时会��D��整个操作�pȝ��不稳定。所以相比之下，�pȝ��资源的泄漏比堆内存的泄漏更�ؓ严重�?/span>

　　GDI Object的泄漏是一�U�常见的资源泄漏�Q?/span>

void CMyView::OnPaint( CDC* pDC )
{
　CBitmap bmp;
　CBitmap* pOldBmp;
　bmp.LoadBitmap(IDB_MYBMP);
　pOldBmp = pDC->SelectObject( &bmp );
　…
　if( Something() ){
　　return;
　}
　pDC->SelectObject( pOldBmp );
　return;
}

　　例二

　　当函数Something()�q�回非零的时候，�E�序在退出前没有把pOldBmp选回pDC中，�q�会��D��pOldBmp指向的HBITMAP对象发生�?漏。这个程序如果长旉��的运行，可能会导致整个系�l�花屏。这�U�问题在Win9x下比较容易暴露出来，因�ؓWin9x的GDI堆比Win2k或NT的要��很多�?/span>

　　内存泄漏的发生方式：

　　以发生的方式来分�c�，内存泄漏可以分�ؓ4�c�：

　　1. 常发性内存泄漏。发生内存泄漏的代码会被多次执行刎ͼ�每次被执行的时候都会导致一块内存泄漏。比如例二，如果Something()函数一直返回True�Q�那么pOldBmp指向的HBITMAP对象��L��发生泄漏�?/span>

　　2. 偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作�q�程下才会发生。比如例二，如果Something()函数只有在特定环境下才返�?True�Q�那么pOldBmp指向的HBITMAP对象�q�不��L��发生泄漏。常发性和偶发性是相对的。对于特定的环境�Q�偶发性的也许��变成了常发性的。所�?��试环境和测试方法对��内存泄漏至关重要�?/span>

　　3. 一�ơ性内存泄漏。发生内存泄漏的代码只会被执行一�ơ，或者由于算法上的缺��P��D��M��有一块仅且一块内存发生泄漏。比如，在类的构造函��C��分配内存�Q�在�?构函��C��却没有释放该内存�Q�但是因��个类是一个Singleton�Q�所以内存泄漏只会发生一�ơ。另一个例子：

char* g_lpszFileName = NULL;

void SetFileName( const char* lpcszFileName )
{
　if( g_lpszFileName ){
　　free( g_lpszFileName );
　}
　g_lpszFileName = strdup( lpcszFileName );
}

　　例三

　　如果�E�序在结束的时候没有释放g_lpszFileName指向的字�W�串�Q�那么，即��多次调用SetFileName()�Q��M��有一块内存，而且仅有一块内存发生泄漏�?/span>

　　4. 隐式内存泄漏。程序在�q�行�q�程中不停的分配内存�Q�但是直到结束的时候才释放内存。严格的说这里�ƈ没有发生内存泄漏�Q�因为最�l�程序释放了所有申��L��内存。但是对于一个服务器�E�序�Q�需要运行几天，几周甚至几个月，不及旉��攑ֆ�存也可能��D��最�l�耗尽�pȝ��的所有内存。所以，我们�U�这�c�d��存泄漏�ؓ隐式内存泄漏。�D一个例子：

class Connection
{
　public:
　　Connection( SOCKET s);
　　~Connection();
　　…
　private:
　　SOCKET _socket;
　　…
};

class ConnectionManager
{
　public:
　　ConnectionManager(){}
　　~ConnectionManager(){
　　　list::iterator it;
　　　for( it = _connlist.begin(); it != _connlist.end(); ++it ){
　　　　delete �Q?it�Q?
　　　}
　　　_connlist.clear();
　　}
　　void OnClientConnected( SOCKET s ){
　　　Connection* p = new Connection(s);
　　　_connlist.push_back(p);
　　}
　　void OnClientDisconnected( Connection* pconn ){
　　　_connlist.remove( pconn );
　　　delete pconn;
　　}
　private:
　　list _connlist;
};

　　例四

　　假设在Client从Server端断开后，Server�q�没有呼叫OnClientDisconnected()函数�Q�那么代表那�ơ连接的 Connection对象��׃��会被及时的删除（在Server�E�序退出的时候，所有Connection对象会在ConnectionManager的析构函数里被删除）。当不断的有�q�接建立、断开旉��式内存泄漏就发生了�?/span>

　　从用户��用程序的角度来看�Q�内存泄漏本�w�不会��生什么危宻I��?��Z��般的用户�Q�根本感觉不到内存泄漏的存在。真正有危害的是内存泄漏的堆�U�，�q�会最�l�消耗尽�pȝ��所有的内存。从�q�个角度来说�Q�一�ơ性内存泄漏�ƈ没有什么危宻I��因�ؓ它不会堆�U�，而隐式内存泄漏危��x��则非常大，因�ؓ较之于常发性和偶发性内存泄漏它更难被检��到�?nbsp;
��内存泄�?/strong>

　　��内存泄漏的关键是要能截获住对分配内存和释放内存的函数的调用。截获住�q�两个函敎ͼ�我们��p��跟踪每一块内存的生命周期�Q�比如，每当成功的分配一块内存后�Q�就把它的指针加入一个全局的list中；每当释放一块内存，再把它的指针从list中删除。这��P��?�E�序�l�束的时候，list中剩余的指针��是指向那些没有被释攄��内存。这里只是简单的描述了检��内存泄漏的基本原理�Q�详�l�的��法可以参见Steve Maguire�?lt;>�?/span>

　　如果要检��堆内存的泄漏，那么需要截获住 malloc/realloc/free和new/delete��可以了�Q�其实new/delete最�l�也是用malloc/free的，所以只要截获前面一�l�即可）。对于其他的泄漏�Q�可以采用类似的�Ҏ��Q�截获住相应的分配和释放函数。比如，要检��BSTR的泄漏，��需要截�?SysAllocString/SysFreeString�Q�要��HMENU的泄漏，��需要截获CreateMenu/ DestroyMenu。（有的资源的分配函数有多个�Q�释攑և�数只有一个，比如�Q�SysAllocStringLen也可以用来分配BSTR�Q�这时就需�?截获多个分配函数�Q?/span>

　　在Windows�q�_��下，��内存泄漏的工具常用的一般有三种�Q�MS C-Runtime Library内徏的检��功能；外挂式的��工��P��诸如�Q�Purify�Q�BoundsChecker�{�；利用Windows NT自带的Performance Monitor。这三种工具各有优缺点，MS C-Runtime Library虽然功能上较之外挂式的工兯��弱，但是它是免费的；Performance Monitor虽然无法标示出发生问题的代码�Q�但是它能检��出隐式的内存泄漏的存在�Q�这是其他两�c�d��h��能�ؓ力的地方�?/span>

　　以下我们详细讨论�q�三�U�检��工��P��

　　VC下内存泄漏的��方�?/span>

　　用MFC开发的应用�E�序�Q�在DEBUG版模式下�~�译后，都会自动加入内存泄漏的检��代码。在�E�序�l�束后，如果发生了内存泄漏，在Debug�H�口中会昄��出所有发生泄漏的内存块的信息�Q�以下两行显�C�Z��一块被泄漏的内存块的信息：

E:/TestMemLeak/TestDlg.cpp(70) : {59} normal block at 0x00881710, 200 bytes long.

Data: 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70

　　�W�一行显�C��内存块由TestDlg.cpp文�g�Q�第70行代码分配，地址�?x00881710�Q�大��ؓ200字节�Q�{59}是指调用内存分配函数�?Request Order�Q�关于它的详�l�信息可以参见MSDN中_CrtSetBreakAlloc()的帮助。第二行昄��该内存块�?6个字节的内容�Q�尖括号内是�?ASCII方式昄��Q�接着的是�?6�q�制方式昄��?/span>

　　一般大安��误以��些内存泄漏的��功能是由MFC提供的，其实不然。MFC只是 ��装和利用了MS C-Runtime Library的Debug Function。非MFC�E�序也可以利用MS C-Runtime Library的Debug Function加入内存泄漏的检��功能。MS C-Runtime Library在实现malloc/free�Q�strdup�{�函数时已经内徏了内存泄漏的��功能�?/span>

　　注意观察一下由MFC Application Wizard生成的项目，在每一个cpp文�g的头部都有这样一�D�宏定义�Q?/span>

#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif

　　有了�q�样的定义，在编译DEBUG版时�Q�出现在�q�个cpp文�g中的所有new都被替换成DEBUG_NEW了。那么DEBUG_NEW是什么呢�Q�DEBUG_NEW也是一个宏�Q�以下摘自afx.h�Q?632�?/span>

#define DEBUG_NEW new(THIS_FILE, __LINE__)

　　所以如果有�q�样一行代码：

char* p = new char[200];

　　�l�过宏替换就变成了：

char* p = new( THIS_FILE, __LINE__)char[200];

　　�Ҏ��C++的标准，对于以上的new的��用方法，�~�译器会��L��q�样定义的operator new�Q?/span>

void* operator new(size_t, LPCSTR, int)

　　我们在afxmem.cpp 63行找��C��一个这��L��operator new 的实�?/span>

void* AFX_CDECL operator new(size_t nSize, LPCSTR lpszFileName, int nLine)
{
　return ::operator new(nSize, _NORMAL_BLOCK, lpszFileName, nLine);
}

void* __cdecl operator new(size_t nSize, int nType, LPCSTR lpszFileName, int nLine)
{
　…
　pResult = _malloc_dbg(nSize, nType, lpszFileName, nLine);
　if (pResult != NULL)
　　return pResult;
　…
}

　　�W�二个operator new函数比较长，��Z��单期��_��我只摘录了部分。很昄��最后的内存分配�q�是通过_malloc_dbg函数实现的，�q�个函数属于MS C-Runtime Library 的Debug Function。这个函��C��但要求传入内存的大小�Q�另外还有文件名和行号两个参数。文件名和行号就是用来记录此�ơ分配是由哪一�D�代码造成的。如果这块内存在�E�序�l�束之前没有被释放，那么�q�些信息��׃��输出到Debug�H�口里�?/span>

　　�q�里��Z��提一下THIS_FILE�Q�__FILE�?__LINE__。__FILE__和__LINE__都是�~�译器定义的宏。当��到__FILE__�Ӟ��~�译器会把__FILE__替换成一个字�W�串�Q�这个字�W�串��是当前在编译的文�g的�\径名。当��到__LINE__�Ӟ��~�译器会把__LINE__替换成一个数字，�q�个数字��是当前�q�行代码的行受��在 DEBUG_NEW的定义中没有直接使用__FILE__�Q�而是用了THIS_FILE�Q�其目的是�ؓ了减��目标文件的大小。假讑֜�某个cpp文�g中有 100处��用了new�Q�如果直接��用__FILE__�Q�那�~�译器会产生100个常量字�W�串�Q�这100个字�W�串都是�?/SPAN>cpp文�g的�\�?名，昄��十分冗余。如果��用THIS_FILE�Q�编译器只会产生一个常量字�W�串�Q�那100处new的调用��用的都是指向帔R��字符串的指针�?/span>

　　再次观察一下由MFC Application Wizard生成的项目，我们会发现在cpp文�g中只对new做了映射�Q�如果你在程序中直接使用malloc函数分配内存�Q�调用malloc的文件名和行 ��h��不会被记录下来的。如果这块内存发生了泄漏�Q�MS C-Runtime Library仍然能检��到�Q�但是当输出�q�块内存块的信息�Q�不会包含分配它的的文�g名和行号�?/span>

　　要在非MFC�E�序中打开内存泄漏的检��功能非常容易，你只要在�E�序的入口处加入以下几行代码�Q?/span>

int tmpFlag = _CrtSetDbgFlag( _CRTDBG_REPORT_FLAG );

tmpFlag |= _CRTDBG_LEAK_CHECK_DF;

_CrtSetDbgFlag( tmpFlag );

　　�q�样�Q�在�E�序�l�束的时候，也就是winmain�Q�main或dllmain函数�q�回之后�Q�如果还有内存块没有释放�Q�它们的信息会被打印到Debug�H�口里�?/span>

　　如果你试着创徏了一个非MFC应用�E�序�Q�而且在程序的入口处加入了以上代码�Q��ƈ且故意在�E�序中不释放某些内存块，你会在Debug�H�口里看��C��下的信息�Q?/span>

{47} normal block at 0x00C91C90, 200 bytes long.

Data: < > 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

　　内存泄漏的确��到了，但是和上面MFC�E�序的例子相比，�~�少了文件名和行受��对于一个比较大的程序，没有�q�些信息�Q�解决问题将变得十分困难�?/span>

　　��Z��能够知道泄漏的内存块是在哪里分配的，你需要实现类似MFC的映��功能，把new�Q�maolloc�{�函数映��到_malloc_dbg函数上。这里我不再赘述�Q�你可以参考MFC的源代码�?/span>

　　�׃��Debug Function实现在MS C-RuntimeLibrary中，所以它只能��到堆内存的泄漏�Q�而且只限于malloc�Q�realloc或strdup�{�分配的内存�Q�而那些系�l�资源，比如HANDLE�Q�GDI Object�Q�或是不通过C-Runtime Library分配的内存，比如VARIANT�Q�BSTR的泄漏，它是无法��到的，�q�是�q�种��法的一个重大的局限性。另外，��Z��能记录内存块是在哪里分配的，源代码必��ȝ��应的配合�Q�这在调试一些老的�E�序非常�ȝ��Q�毕竟修�Ҏ��代码不是一件省心的事，�q�是�q�种��法的另一个局限性�?/span>

　　�?于开发一个大型的�E�序�Q�MS C-Runtime Library提供的检��功能是�q�远不够的。接下来我们��q��看外挂式的检��工兗��我用的比较多的是BoundsChecker�Q�一则因为它的功能比较全面，更重要的是它的稳定性。这�c�d��具如果不�E�_��Q�反而会忙里��Mؕ。到底是��鼎鼎大名的NuMega�Q�我用下来基本上没有什么大问题�?/span>
使用BoundsChecker��内存泄漏：

　　BoundsChecker采用一�U�被�U�Cؓ Code Injection的技术，来截获对分配内存和释攑ֆ�存的函数的调用。简单地��_��当你的程序开始运行时�Q�BoundsChecker的DLL被自动蝲入进 �E�的地址�I�间�Q�这可以通过system-level的Hook实现�Q�，然后它会修改�q�程中对内存分配和释攄��函数调用�Q�让�q�些调用首先转入它的代码�Q�然�?再执行原来的代码。BoundsChecker在做�q�些动作的时�Q�无��M��改被调试�E�序的源代码或工�E�配�|�文�Ӟ��q��得��用它非常的简�ѝ��直接�?/span>

　　�q�里我们以malloc函数��Z��Q�截获其他的函数�Ҏ��与此�c�M��?/span>

　　需要被截获的函数可能在DLL中，也可能在�E�序的代码里。比如，如果静态连�l�C-Runtime Library�Q�那么malloc函数的代码会被连�l�到�E�序里。�ؓ了截获住对这�c�d��数的调用�Q�BoundsChecker会动态修改这些函数的指��o�?/span>

　　以下两段汇编代码�Q�一�D�|��有BoundsChecker介入�Q�另一�D�则有BoundsChecker的介入：

126: _CRTIMP void * __cdecl malloc (
127: size_t nSize
128: )
129: {

00403C10 push ebp
00403C11 mov ebp,esp
130: return _nh_malloc_dbg(nSize, _newmode, _NORMAL_BLOCK, NULL, 0);
00403C13 push 0
00403C15 push 0
00403C17 push 1
00403C19 mov eax,[__newmode (0042376c)]
00403C1E push eax
00403C1F mov ecx,dword ptr [nSize]
00403C22 push ecx
00403C23 call _nh_malloc_dbg (00403c80)
00403C28 add esp,14h
131: }

　　以下�q�一�D�代码有BoundsChecker介入�Q?/span>

126: _CRTIMP void * __cdecl malloc (
127: size_t nSize
128: )
129: {

00403C10 jmp 01F41EC8
00403C15 push 0
00403C17 push 1
00403C19 mov eax,[__newmode (0042376c)]
00403C1E push eax
00403C1F mov ecx,dword ptr [nSize]
00403C22 push ecx
00403C23 call _nh_malloc_dbg (00403c80)
00403C28 add esp,14h
131: }

　　当BoundsChecker介入后，函数malloc的前三条汇编指��o被替换成一条jmp指��o�Q�原来的三条指��o被搬到地址01F41EC8处了。当�E?序进入malloc后先jmp�?1F41EC8�Q�执行原来的三条指��o�Q�然后就是BoundsChecker的天下了。大致上它会先记录函数的�q�回地址 �Q�函数的�q�回地址在stack上，所以很�Ҏ��修改�Q�，然后把返回地址指向属于BoundsChecker的代码，接着跛_��malloc函数原来的指令，�?��是�?0403c15的地斏V��当malloc函数�l�束的时候，�׃��q�回地址被修改，它会�q�回到BoundsChecker的代码中�Q�此�?BoundsChecker会记录由malloc分配的内存的指针�Q�然后再跌��{到到原来的返回地址厅R�?/span>

　　如果内存分配/释放函数在DLL中，BoundsChecker则采用另一�U�方法来截获对这些函数的调用。BoundsChecker通过修改�E�序的DLL Import Table让table中的函数地址指向自己的地址�Q�以辑ֈ�截获的目的�?/span>

　　截获住这些分配和释放函数�Q�BoundsChecker��p��记录被分配的内存或资源的生命周期。接下来的问题是如何与源代码相关�Q�也��是说当 BoundsChecker��到内存泄漏�Q�它如何报告�q�块内存块是哪段代码分配的。答案是调试信息�Q�Debug Information�Q�。当我们�~�译一个Debug版的�E�序�Ӟ��~�译器会把源代码和二�q�制代码之间的对应关�p�记录下来，攑ֈ�一个单独的文�g�?(.pdb)或者直接连�l�进目标�E�序�Q�通过直接��d��调试信息��p��得到分配某块内存的源代码在哪个文�Ӟ��哪一行上。��用Code Injection和Debug Information�Q��BoundsChecker不但能记录呼叫分配函数的源代码的位置�Q�而且�q�能记录分配时的Call Stack�Q�以及Call Stack上的函数的源代码位置。这在��用像MFC�q�样的类库时非常有用�Q�以下我用一个例子来说明�Q?/span>

void ShowXItemMenu()
{
　…
　CMenu menu;

　menu.CreatePopupMenu();
　//add menu items.
　menu.TrackPropupMenu();
　…
}

void ShowYItemMenu( )
{
　…
　CMenu menu;
　menu.CreatePopupMenu();
　//add menu items.
　menu.TrackPropupMenu();
　menu.Detach();//this will cause HMENU leak
　…
}

BOOL CMenu::CreatePopupMenu()
{
　…
　hMenu = CreatePopupMenu();
　…
}

　　当调用ShowYItemMenu()�Ӟ��我们故意造成HMENU的泄漏。但是，对于BoundsChecker来说被泄漏的HMENU是在class CMenu::CreatePopupMenu()中分配的。假讄��你的�E�序有许多地方��用了CMenu的CreatePopupMenu()函数�Q�如 CMenu::CreatePopupMenu()造成的，你依然无法确认问题的根结到底在哪里，在ShowXItemMenu()中还是在 ShowYItemMenu()中，或者还有其它的地方也��用了CreatePopupMenu()�Q�有了Call Stack的信息，问题��容易了。BoundsChecker会如下报告泄漏的HMENU的信息：

Function
File
Line

CMenu::CreatePopupMenu
E:/8168/vc98/mfc/mfc/include/afxwin1.inl
1009

ShowYItemMenu
E:/testmemleak/mytest.cpp
100

　　�q�里省略了其他的函数调用

　　如此�Q�我们很�Ҏ��扑ֈ�发生问题的函数是ShowYItemMenu()。当使用MFC之类的类库编�E�时�Q�大部分的API调用都被��装在类库的class里，有了Call Stack信息�Q�我们就可以非常�Ҏ��的追�t�到真正发生泄漏的代码�?/span>

　　记录Call Stack信息会�ɽE�序的运行变得非常慢�Q�因此默认情况下BoundsChecker不会记录Call Stack信息。可以按照以下的步骤打开记录Call Stack信息的选项开养I��

　　1. 打开菜单�Q�BoundsChecker|Setting…

　　2. 在Error Detection��中�Q�在Error Detection Scheme的List中选择Custom

　　3. 在Category的Combox中选择 Pointer and leak error check

　　4. 钩上Report Call Stack复选框

　　5. 点击Ok

　　��Z��Code Injection�Q�BoundsChecker�q�提供了API Parameter的校验功能，memory over run�{�功能。这些功能对于程序的开发都非常有益。由于这些内容不属于本文的主题，所以不在此详述了�?/span>

　　��管BoundsChecker的功能如此强大，但是面对隐式内存泄漏仍然昑־�苍白无力。所以接下来我们看看如何用Performance Monitor��内存泄漏�?/span>

　　使用Performance Monitor��内存泄�?/span>
　　NT的内核在设计�q�程中已�l�加入了�pȝ��监视功能�Q�比�?/span>CPU的��用率�Q�内存的使用情况�Q�I/O操作的频�J�度�{�都作�ؓ一个个Counter�Q�应用程序可以通过��d��q�些Counter了解整个�pȝ��的或者某个进�E�的�q�行状况。Performance Monitor��是�q�样一个应用程序�?/span>

　　��Z��内存泄漏，我们一般可以监视Process对象的Handle Count�Q�Virutal Bytes 和Working Set三个Counter。Handle Count记录了进�E�当前打开的HANDLE的个敎ͼ�监视�q�个Counter有助于我们发现程序是否有Handle泄漏�Q�Virtual Bytes记录了该�q�程当前在虚地址�I�间上��用的虚拟内存的大��，NT的内存分配采用了两步走的�Ҏ��Q�首先，在虚地址�I�间上保留一�D늩��_��q�时操作�pȝ��q?没有分配物理内存�Q�只是保留了一�D�地址。然后，再提交这�D늩��_��q�时操作�pȝ��才会分配物理内存。所以，Virtual Bytes一般��d��于程序的Working Set。监视Virutal Bytes可以帮助我们发现一些系�l�底层的问题; Working Set记录了操作系�l��ؓ�q�程已提交的内存的总量�Q�这个值和�E�序甌��的内存总量存在密切的关�p�，如果�E�序存在内存的泄漏这个��g��持箋增加�Q�但�?Virtual Bytes却是跌��式增加的�?/span>
　　监视�q�些Counter可以让我们了解进�E��用内存的情况�Q�如果发生了泄漏�Q�即使是�?式内存泄漏，�q�些Counter的��g��会持�l�增加。但是，我们知道有问题却不知道哪里有问题�Q�所以一般��用Performance Monitor来验证是否有内存泄漏�Q�而��用BoundsChecker来找到和解决�?/span>
　　当Performance Monitor昄��有内存泄漏，而BoundsChecker却无法检��到�Q�这时有两种可能�Q�第一�U�，发生了偶发性内存泄漏。这时你要确保��?Performance Monitor和��用BoundsChecker�Ӟ��E�序的运行环境和操作�Ҏ��是一致的。第二种�Q�发生了隐式的内存泄漏。这时你要重新审查程序的设计�Q�然后仔�l�研�I�Performance Monitor记录的Counter的值的变化图，分析其中的变化和�E�序�q�行逻辑的关�p�，扑ֈ�一些可能的原因。这是一个痛苦的�q�程�Q�充满了假设、猜惟뀁验证、失败，但这也是一个积累经验的�l�好��Z��?/span>
　　�ȝ��
　　内存泄漏是个大而复杂的问题�Q�即使是Java�?Net�q�样�?Gabarge Collection机制的环境，也存在着泄漏的可能，比如隐式内存泄漏。由于篇�q�和能力的限�Ӟ��本文只能对这个主题做一个粗��的研究。其他的问题�Q�比�?多模块下的泄漏检��，如何在程序运行时对内存��用情况进行分析等�{�，都是可以深入研究的题目。如果您有什么想法，��或发��C��某些错误�Q�欢�q�和我交��?/span>

鑫龙 2012-11-06 21:04 发表评论

久久99热这里只有精品国产,97久久精品国产精品青草,国产精品美女久久久久久2018

函数调用�U�定�Q�_stdcall�Q�_cdecl�Q�_fastcall (�?

左值和叛_��|��转）

左值右�?/span>

拯���构造函数和赋值操作函数的参数��Z��么是const�?amp;?!

C++模板元编�E?入门����?(�?

C++模板元编�E?入门����?/a>

Traits 技�?--- 模板元编�E?(�?

C++�c�d��转换�ȝ��(�?

c++ cout 格式化输�?�?

cout 格式化输�?/a>

c++内存泄露机制(�?

拯��构造函数和赋值操作函数的参数��Z��么是const�?amp;?!

C++模板元编�E?入门��?(�?

C++模板元编�E?入门��?/a>