博客园_SolidMango

《Effective STL》读书总结--关于STL 你不一定都懂的

2012-02-10T10:30:00Z

春节期间一次用手机上网无意间发现了这本书，说起来还得感谢智能手机的发展，有时候还是很方便的。当时随便的翻了几页，于是我停不下来了，因为我发现原来我不知道的东西太多了。

我第一次接触STL的时候大约在7年前，那个时候刚从C语言转到C++，记得那个时候知道了STL 的vector, list, map, 但是只是把这些东西当作C++的语法，一带而过，用的时候查查文档，只要逻辑和结果对了就OK，到处是for循环，到处是迭代器，现在回想起来的感触是：… 没文化，真可怕。

第二次我想深入学习STL的时候是研究生毕业以后，记得那个时候刚入行，公司的产品出现了一个问题，是关于STL 的一个容器的erase() 方法调用问题，自己搞了半天才看懂，原来这一个特殊的情况下，这种用法有问题。为了扫清这类问题，我决定深入的学习一下STL。当时找到了一本侯捷翻译的《STL 源码剖析》，说实话，这本书写的真不错，但是他写的有点枯燥，迭代器，分配器… 你没点坚定的毅力说不定就败给他了，我花了一个月的时间(下班后) 才啃完这本书，不敢说100% 扫平，80%还是有的，但是当我读完的时候，我发现这并不是我想要的，我虽然理解了作者要表达的东西，读懂了分配器，迭代器的原理，但是在我的工作中用到的地方并不多。

第三次，也就是这次，当我看到《Effective STL》的时候，我的感触是相见恨晚，做C++开发要是不知道这些东西，显然不够格。其实每种技术都有他自己的特点，都有他自己的取舍，你如果想使用STL就要按照他的方式来玩，我们平时的主官感觉对STL来说并不一定都适用。什么时候用什么容器，什么时候用什么迭代器，什么时候用什么算法，什么时候不该用循环，这本书都做了解答，可以不夸张的说，这本书看过了才能说自己会用STL了。

当然我们要承认，这个世界是有高人的，如果您能正确的回答我下面的几个问题，那估计您不需要读了。

1. STL 标准序列容器和关联容器都是什么？有什么区别？非标准的呢？

2. STL 迭代器有几种都有什么区别？

3. 在什么情况下用什么容器？

4. 什么情况下vector可以比map效率高？

5. 如何写一个自己的内存分配器？

6. 如何调整vector的内存容量，节省内存？

7. 如何修改multiset的键？

8. 如何写仿函数类？

如果您不用上网查就都知道答案，那么恭喜您，您是STL大牛。

如果您懂超过5个，那么同样恭喜您，您至少算个合格的高级工程师。

如果您对超过一半都不知所措，那您也该考虑充充电了。

本文链接

2011总结，2012展望，生活技术都不能少

2012-01-18T08:10:00Z

2011总结，2012展望，生活技术都不能少

转眼间2012年已悄然来临，春节将至，和大部分的朋友一样，有感于时光飞逝，在这个特别的阶段总想总结一下过去，并展望一下美好的未来，为新的一年做个规划。

总结

身体是革命的本钱，先来说说身体，2011年基本能保证每周打一次羽毛球，一次篮球，每次各两个小时，打完球洗个温水澡，睡个懒觉，这也许就是人生最大的追求了。

外语方面，英语水平稳中有升，单词量也多了一些，本来年初的时候有计划把日语捡起来，后来因为时间不够，没能实施，做个trilingual 的中国牛，不容易啊..

技术方面，主要精力集中在windows开发方面，正如有些兄弟说的，技术这个东西，你每做一次都会有更深入的理解。

2011年重温了《Effective C++》《More Effective C++》《组件对象模型》《COM本质论》对C++的理解和以前的自己比，应该算是更上一层楼了。

.NET 方面通读和挑选了几本中英文的书籍，重点挑选自己以前没注意的和忽略的技术进行研究主要包括：Linq to object, 闭包，协变逆变，以及WCF，其中WCF我只进行了相关的技术学习，写了一些测试的Demo，由于在实际的项目实施中没机会使用，感觉还欠火候，准备有时间继续学习。

调试技术方面，不管实时调试还是事后调试，就非托管代码而言，在什么情况下该用什么样的工具，遇到什么样的问题如何处理可以说已经了然于胸，剩下的只有积累经验，多做多学，其实就是这样，付出越多收获才会越多，不是谁天生就比别人牛很多，都是良性循环的积累的。非托管代码是努力的目标，新的一年准备做一些SOS方面的学习。

基础知识方面，本来年初计划把剩下的一些《算法导论》的内容读完，但是还是没坚持下来，有些算法确实有些晦涩，而且不常用，作为兴趣爱好，时间不够只能往后排，不过也不是完全没有收获，读了一本《数据结构算法与应用C语言描述》，至少常用的数据结构知识又重新温习了一遍。新的一年打算重新研究一些编译原理，重新读一遍龙书，上学的时候是挑着读的，这次打算研读一番..

技术类比和知识扩展方面，2011年出于兴趣和好奇，读了《Learning Python》《JavaScript 高级编程》, 其实工作中这两种技术很少使用，但是经常听见圈里的朋友提起，所以就尝试着学习一下，东西不难，但是值得借鉴的地方还是不少的。

Linux 方面本来计划2011年找个开源的项目跟进一下，一是为开源社区做些贡献，另一方面自己也可以学习一下工作中接触不到的东西，尝试过几次，但是始终没有找到Linux下面规模适合的开源的项目，也可能是小弟没太用心，一直没有找到，如果哪位兄弟了解希望多多指教，在整个2011年，Linux方面只是学习了标准的Make file的写法，Shell, GDB , 进步有限，希望在新的一年里能多花些精力在上面。

Java 代码2011年写的也很少，作为与.net 的类比，他们实在有太多的相似，2011年一年在Java方面的收获仅限于《Java 核心技术》I卷通读一遍，算是温故知新吧。

展望

身体始终是第一位的，2011年的锻炼至少在量上面还是比较成功的，新的一年要再接再厉，锻炼不能只为出点汗，羽毛球和篮球的球技是该提高的时候了，有时间多向高手学习一下，看看相关的视频，请请教练，生活本来可以更美好的, 另外如果时间允许希望可以把游泳学了，这个要真是2012年底就世界末日，小弟还不会游泳呢..

英语方面，希望在词汇，听力，口语方面有所突破，现在虽然和外国友人交流没什么问题，但是总觉得不知道该说些什么好，有待提高啊，如果有时间，日语还是最好学习一下，谁知道哪天日本又出什么NB动画片了，不懂日语就out 了。

技术方面，

C/C++ 不想再读新书了，除非有特别好的，可以打动我，我希望把手里面的C/C++ 方面的书籍和资料整理一些，温故知新，相信量已经到了，希望籍此发生质变。

调试技术方面水还是很深的，非托管代码的调试技术需要加强，做更多的项目时注意积累这方面的经验，相关的技术知识从新整理一遍，托管代码的SOS是自己今年的主要的扩展方向。

.NET 方面，因为这个是工作的主攻方向，准备选择1，2本书总结一下相关的知识，扫清盲点，特别是内部机理方面的知识。WCF需要大彻大悟啦，估计项目马上就会使用这方面的知识。

基础知识方面《算法导论》需要读完，另外编译原理的英文版龙书需要研读一遍，翻译版的龙书实在不敢恭维。

技术类比和扩展方面如果有感兴趣的东西，希望有时间可以选择1到2种进行学习。

Linux开发和Java开发希望在今年可以跟进一两个开源的项目。

软件开发的上层建筑设计模式和UML一直在学习，但是感觉还是不能游刃有余，估计是这方面做的想得都不够，所以这方面要努力啊，新的一年希望可以透彻的运用这两项技能，把以前看过的资料和做过的项目都总结一下，尽量画UML，如果可能的话做一下相关的改进。

写了不少，算是给今年画个完整的结束吧.

天行健，君子自强不息，愿大家过个欢乐祥和的春节…

本文链接

Windows程序员需要学什么

2011-11-26T02:45:00Z

经常发现有人在网上提出这样的问题，现实中也确实有不少人在经历了3-5年的Windows开发之后就开始迷失方向，每天浑浑噩噩混日子，可能是因为这个问题粒度太大，没人愿意花时间回答，希望本文可以抛砖引玉，给大家节省些时间，同时也希望园子里面的兄弟们能尽力的补充，从而使这篇文章可以帮助更多的后来人。

首先说明的是，本文提到的各种技术不分先后，没有顺序，虽然先学什么，再学什么对某些人来说可能更方便，但是这些都不是绝对的，因为每个人的情况不同。

Windows开发首先必须学习的就是操作系统的API，因为其他的一切都是构建于OS之上，所谓九层之台，起于垒土，如果你对linux的系统调用很熟悉就会发现其实他们大同小异，都是应用程序在使用系统提供的功能。

接下来是MFC，有了MFC你才真正的可以干点开发，因为MFC实在是太全了，几乎封装了所有的Windows API, 消息循环，COM实现…

到了此地，你可以开始学习调试技术了，熟悉了调试的各种技巧才可以做到事半功倍，得心应手。

接下来是组建对象模型COM，作为windows的基石，不懂COM，很难说自己精通windows编程，因为即使现在的.NET framework也是构建于COM之上，很多问题还是需要SOS到底层去调试。

当你懂得了COM的精髓，你应该开始学习ATL了，这个类库可以使你的COM开发更加得心应手。

说到ATL就不能不提到他的前辈STL，这个出自于标准C++的类库在windows上同样也得到了很好的支持，有了STL在你有一天想转linux开发也同样会用得上。

Windows 8中的WinRT现在还没有应用于实际开发，现有的技术中.NET 是非常值得学习的，因为.NET 的主旨是提高程序员的开发效率，在这个浮躁的世界，开发效率有时候能够代表一切。

从COM到.NET只有一步之遥，.NET 其实是从COM+演化而来，具体细节请参看 Don Box的《.NET 本质论》了解了这些会使你对.NET的认识上升到一个新的层面。

接下来是C# 因为这家伙是.NET的嫡系部队，除了IL，这家伙可以说和.NET 的关系最为亲近，大部分的新功能都会最先在其中加以体现。当你熟悉了C#， BCL，《CLR via C#》可以说这个时候你已经可以胜任基本的C#开发了，可以很快写出一个小工具，完成一个相关的task。

接下来是WCF和WPF，做分布式开发少不了WCF，同样华丽的界面少不了XAML，WPF。

大概罗列了一些，其实每个主题仔细探究下去都很有韵味，还有需要说的是，其实Windows上面好多的东西都和UNIX很像，比如PowerShell明显是为了像UNIX一样，给开发者提供一个更强大的shell, 如果有兴趣，触类旁通一下，也很是有趣。

还有：

LINQ改变了我们的数据操作方式，统一了数据操作模型，经常操作数据的兄弟，你值得拥有。

F#作为一种函数式编程语言也很值得研究，由于本人使用不多，在此不作评价。

另外：

作为基础的算法；

作为提升功力的设计模式，UML；

作为改善系统性能的重构；

作为大部分分布式核心的TCP/IP；

等等主题也是值得大家研究的。

最后借鲁迅的话收尾：其实地上本没有路，走的人多了也便成了路，希望大家不要把时间都浪费了，原来还有好多东西可以去钻研。

不当之处望大家批评、指正、拍砖, 并提出您的宝贵的意见和补充。

本文链接

C# 语言表现树形结构—TreeView高级用法指南

2011-11-16T05:52:00Z

最近由于项目的关系，对Microsoft在各种编程语言中提供的TreeView控件做了一些研究。最初在网上查了一下，除了Microsoft的MSDN有些分散的knowledge, 并没有发现有这方面主题文章，于是有了写这篇文章的想法，希望可以抛砖引玉，让后来人少走些弯路。

出于个人兴趣的关系，我主要对Microsoft Visual C++ 和C#两种语言中的TreeView控件进行了相应的研究，在这两种语言中，对于TreeView控件的基本用法本文不做说明，相对高级的用法主要是为TreeItem设置静态图标和选中图标，drag and drop操作，由于C#中的TreeView控件是所有微软提供的TreeView控件中相对完整，而且设计相对优雅的一个，下面以C#中TreeView控件为例就相应的主题分别说明。

先来看看MSDN上给C# TreeView控件的定义：

Displays a hierarchical collection of labeled items, each represented by a TreeNode.

翻译：表现一组有继承结构关系的带有标签的项的集合，每个标签项由TreeNode来表现。也就是说TreeNode表现树的节点，主要工作由它来承担。

那么如何为TreeNode设置图像呢？

如下文字来自MSDN：

可以在树节点旁显示图像，方法是将一个 ImageList 分配给 ImageList 属性，然后通过引用 Image 在 ImageList 中的索引值来分配该 Image。

使用下面的属性分配图像：

将 ImageIndex 属性设置为当树节点未选定时所显示的 Image 的索引值。

将 SelectedImageIndex 属性设置为当树节点被选定时要显示的 Image 的索引值。

ImageIndex 和 SelectedImageIndex 属性值所引用的图像是所有分配给 Nodes 集合的树节点显示的默认图像。每个树节点都可以通过设置 TreeNode.ImageIndex 和 TreeNode.SelectedImageIndex 属性来取代默认的图像。

看完了这段文字，你知道该如何操作了么？我觉得可能有好多人还是不是完全的理解，那我们就已程序员的语言来描述一下吧:

首先定义一个ImageList变量并将其赋值给TreeView的ImageList，

1 private System.Windows.Forms.ImageList imageList007;
2 this.imageList007 = new System.Windows.Forms.ImageList(this.components);
3 this.treeView1.ImageList = this.imageList007;

然后需要对图标进行设置,

this.imageList007.ImageStream =

((System.Windows.Forms.ImageListStreamer)(resources.GetObject("imageList007.ImageStream")));
this.imageList007.TransparentColor = System.Drawing.Color.Transparent;
this.imageList007.Images.SetKeyName(0, "Icon01.ico");
this.imageList007.Images.SetKeyName(1, "Icon02.ico");
this.imageList007.Images.SetKeyName(2, "Icon03.ico");
this.imageList007.Images.SetKeyName(3, "Icon04.ico");
this.imageList007.Images.SetKeyName(4, "Icon05.ico");

最后可以对TreeView 的ImageIndex 和 SelectedImageIndex 属性进行相应的设置，选择相应的图像，也可以对每个动态生成的节点进行独立的图像设置，到此你已经成功的设置了TreeNode的图像。

那又如何实现Drag and Drop 操作呢？

首先我们需要清楚Drag and Drop的源和目标都是什么，也就是说从哪向哪拖拽，每个部分承担的职责是什么，而只有在源和目标上都做了相应的处理，拖拽过程才可能是完整有效的。

源组件处理：

ItemDrag事件: 当鼠标开始对源树节点进行拖拽的时候，会引发这个事件，也就是说这个事件的发出者应该是源组件，在这个事件处理函数中需要调用DoDragDrop方法初始化并开始一个拖拽过程。

目标组件处理：

DragEnter事件: 当初始化操作结束以后，我们需要在拖拽目标处处理DragEnter事件，这个事件发生在源节点被拖动到目标组件范围内的某个点的时候，在这个事件中我们可以对这个拖拽的合法性进行验证，并且设置不同的鼠标形状来表示不同的状态，DragDropEffects 结构用于对鼠标形状进行设置。

目标组件处理：

DragDrop 事件: 这个事件用于在目标组件中处理拖拽事件，发生于源节点已经被拖拽到目的组件处，这时我们可以对拖拽过来的节点进行解析处理等实际工作。

注意:为了完成拖拽操作源组件和目标组件的AllowDrop都需要设置成true.

示例代码，如下代码完成了将一个TreeNode拖拽到一个Form上需要完成的工作：

private void UsingTreeViewDemo_Load(object sender, EventArgs e)
{
   this.treeView1.ItemDrag += new System.Windows.Forms.ItemDragEventHandler(this.treeView_ItemDrag);
   this.DragEnter += new System.Windows.Forms.DragEventHandler(this.Form_DragEnter);
   this.DragDrop += new System.Windows.Forms.DragEventHandler(this.Form_DragDrop);
}

private void treeView_ItemDrag(object sender, System.Windows.Forms.ItemDragEventArgs e)
{
    DoDragDrop(e.Item, DragDropEffects.Copy);
}

private void Form_DragEnter(object sender, System.Windows.Forms.DragEventArgs e)
{
    e.Effect = DragDropEffects.Copy;
}

private void Form_DragDrop(object sender, System.Windows.Forms.DragEventArgs e)
{
    TreeNode NewNode;
    if (e.Data.GetDataPresent("System.Windows.Forms.TreeNode", false))
    {
          NewNode = (TreeNode)e.Data.GetData("System.Windows.Forms.TreeNode");
          MessageBox.Show(NewNode.ToString());
    }
}

至此，本文的使命已经完成，相信大家已经熟悉了这两项相对高级的TreeView用法。欢迎大家就此主题互相讨论，并对本文的不当之处批评指正。

本文链接

一句话清晰总结协变和逆变

2011-11-09T05:32:00Z

看到过园子里面几篇协变和逆变的文章，但是总觉得写得不够清晰，文章这东西注重要是要把自己想表达的观点表达出来，这个过程应该是把复杂的东西消化出来从而简单化，清晰化，而不是故弄玄虚，反其道而行之，下面我们言归正传啦。

我们先来看一段MSDN原文给协变，逆变和变体下个定义：

A generic interface or delegate is called variant if its generic parameters are declared covariant or contravariant. Both C# and Visual Basic enable you to create your own variant interfaces and delegates.

如果泛型接口或委托的泛型参数声明为协变或逆变，则将该泛型接口或委托称为“变体”。 C# 和 Visual Basic 都允许您创建自己的变体接口和委托。

通俗解释：

变体定义：带有协变或逆变参数的泛型接口或委托。也就是说协变和逆变主要关注点在泛型接口或委托。

那什么又是协变和逆变呢？

我们先来看下面一个来自MSDN的例子：

1 // 协变
2 IEnumerable<string>strings = new List<string>();
3 IEnumerable<object> objects = strings;

大家看到了么一个声明为IEnumerable<string>的接口类型被赋给了一个更低级别的IEnumerable<object>.

对，这就是协变。再来看一个例子：

class Base

{

public static void PrintBases(IEnumerable<Base> bases)

{

foreach(Base b in bases)

{

Console.WriteLine(b);

}

class Derived : Base

{

public static void Main()

{

List<Derived> dlist = new List<Derived>();

Derived.PrintBases(dlist);//由于IEnumerable<T>接口是协变的，所以PrintBases(IEnumerable<Base> bases)

//可以接收一个更加具体化的IEnumerable<Derived>作为其参数。

IEnumerable<Base> bIEnum = dlist;

}

下面给协变下个定义：

协变：让一个带有协变参数的泛型接口（或委托）可以接收类型更加精细化，具体化的泛型接口（或委托）作为参数，可以看成OO中多态的一个延伸。

// 逆变
// Assume that the following method is in the class:
// static void SetObject(object o) { }
Action<object> actObject = SetObject;
Action<string> actString = actObject;

//委托actString中以后要使用更加精细化的类型string不能再使用object啦！
string strHello(“Hello”);
actString(strHello);

大家看到了么？一个声明为Action<object>的类型被赋给了一个Action<string>，大家都知道，Action<T>接收参数，没有返回值，所以其中的object和string是其参数，这个过程其实就是参数的约束更加强了，也就是说让参数类型更加精细化。下面我们来给逆变下个定义：

逆变：让一个带有协变参数的泛型接口（或委托）可以接收粒度更粗的泛型接口或委托作为参数，这个过程实际上是参数类型更加精细化的过程。

一句话总结：协变让一个粗粒度接口（或委托）可以接收一个更加具体的接口（或委托）作为参数（或返回值）；逆变让一个接口（或委托）的参数类型（或返回值）类型更加具体化，也就是参数类型更强，更明确。

通常，协变类型参数可用作委托的返回类型，而逆变类型参数可用作参数类型。对于接口，协变类型参数可用作接口的方法的返回类型，而逆变类型参数可用作接口的方法的参数类型。

本文链接

.Net Framework的前世今生--各个版本的新增功能

2011-10-11T11:20:00Z

1.0--3.5sp1

http://msdn.microsoft.com/zh-cn/library/ms171868(v=VS.90).aspx

4.0

http://msdn.microsoft.com/zh-cn/library/ms171868(v=VS.100).aspx

本文链接

C# 编码约定

2011-10-10T13:15:00Z

C# 语言规范没有定义编码标准。但是，Microsoft 使用本主题中的这些指南开发示例和文档。

编码约定可实现以下目的：

它们创建一致的代码外观，从而使读者可以关注内容而非布局。
它们使读者能够根据以前的经验作出假设，从而更加快速地理解代码。
有利于复制、更改和维护代码。
演示 C# 最佳做法。

命名约定

命名指南在名称准则中介绍。
您无需更改由 Visual Studio 设计器工具创建的对象的名称，就可以让它们符合指南。
在不包括 using 语句的简短示例中，使用命名空间限定。如果您知道默认情况下会将某命名空间导入项目中，则无需完全限定来自该命名空间的名称。如果限定名称太长无法放入一行，则可在点 (.) 后截断它，如以下示例所示。
var currentPerformanceCounterCategory = new System.Diagnostics. PerformanceCounterCategory();

布局约定

好的布局使用格式设置来强调代码的结构，并使该代码更易于阅读。 Microsoft 示例符合以下约定：

使用默认代码编辑器设置（智能缩进、四字符缩进、将制表符保存为空格）。有关更多信息，请参见“选项”对话框 ->“文本编辑器”->“C#”->“格式设置”。
每行仅编写一个语句。
每行仅编写一个声明。
如果续行不自动缩进，将它们缩进一个制表位（四个空格）。
在方法定义和属性定义之间添加至少一个空白行。

使用括号突显表达式中的子句，如下面的代码所示。

if ((val1 > val2) && (val1 > val3))
{
    // Take appropriate action.
}

注释约定

将注释放到另一行，而不要放在代码行的末尾。
以大写字母作为注释文本的开头。
以句点结束注释文本。
在注释分隔符 (//) 和注释文本之间插入一个空格，如以下示例所示。
// The following declaration creates a query. It does not run // the query.
请勿在注释周围创建已设置格式的星号块。

语言指南

以下各部分描述了 C# 团队准备代码示例时遵循的做法。

String 数据类型

使用 + 运算符来连接短字符串，如以下代码所示。

string displayName = nameList[n].LastName + ", " + nameList[n].FirstName;

若要在循环中附加字符串，尤其是在您处理大量文本时，请使用 StringBuilder 对象。

var phrase = "lalalalalalalalalalalalalalalalalalalalalalalalalalalalalala";
var manyPhrases = new StringBuilder();
for (var i = 0; i < 10000; i++)
{
    manyPhrases.Append(phrase);
}
//Console.WriteLine("tra" + manyPhrases);

隐式类型化局部变量

如果赋值语句右侧的变量类型十分明显，或在精确的类型并不重要时，使用隐式类型的局部变量。

// When the type of a variable is clear from the context, use var 
// in the declaration.
var var1 = "This is clearly a string.";
var var2 = 27;
var var3 = Convert.ToInt32(Console.ReadLine());

赋值语句右侧的类型不明显时，不要使用 var。

// When the type of a variable is not clear from the context, use an
// explicit type.
int var4 = ExampleClass.ResultSoFar();

不要依赖变量名来指定变量的类型。这可能是不正确的。

// Naming the following variable inputInt is misleading. 
// It is a string.
var inputInt = Console.ReadLine();
Console.WriteLine(inputInt);

避免使用 var 取代 dynamic。

使用隐式类型在 for 和 foreach 循环中确定循环变量的类型。

下面的示例在 for 语句中使用了隐式类型。

var syllable = "ha";
var laugh = "";
for (var i = 0; i < 10; i++)
{
    laugh += syllable;
    Console.WriteLine(laugh);
}

下面的示例在 foreach 语句中使用了隐式类型。

foreach (var ch in laugh)
{
    if (ch == 'h')
        Console.Write("H");
    else
        Console.Write(ch);
}
Console.WriteLine();

无符号数据类型

一般情况下，使用 int 而不是无符号类型。在整个 C# 中，使用 int 很常见，并且在您使用 int 时很容易与其他库进行交互。

数组

在您初始化声明行上的数组时，请使用简洁的语法。

// Preferred syntax. Note that you cannot use var here instead of string[].
string[] vowels1 = { "a", "e", "i", "o", "u" };


// If you use explicit instantiation, you can use var.
var vowels2 = new string[] { "a", "e", "i", "o", "u" };

// If you specify an array size, you must initialize the elements one at a time.
var vowels3 = new string[5];
vowels3[0] = "a";
vowels3[1] = "e";
// And so on.

委托

请使用简洁的语法来创建委托类型的实例。

// First, in class Program, define the delegate type and a method that // has a matching signature.// Define the type.publicdelegatevoid Del(string message);

// Define a method that has a matching signature.publicstaticvoid DelMethod(string str)
{
Console.WriteLine("DelMethod argument: {0}", str);
}

// In the Main method, create an instance of Del.// Preferred: Create an instance of Del by using condensed syntax.
Del exampleDel2 = DelMethod;

// The following declaration uses the full syntax.
Del exampleDel1 = new Del(DelMethod);

异常处理中的 try-catch 和 using 语句

为大多数异常处理使用 try-catch 语句。

static string GetValueFromArray(string[] array, int index)
{
    try
    {
        return array[index];
    }
    catch (System.IndexOutOfRangeException ex)
    {
        Console.WriteLine("Index is out of range: {0}", index);
        throw;
    }
}

使用 C# using 语句简化代码。如果有一个 try-finally 语句，其中 finally 块中的唯一代码为对 Dispose 方法的调用，请改用 using 语句。

// This try-finally statement only calls Dispose in the finally block.
Font font1 = new Font("Arial", 10.0f);
try
{
    byte charset = font1.GdiCharSet;
}
finally
{
    if (font1 != null)
    {
        ((IDisposable)font1).Dispose();
    }
}


// You can do the same thing with a using statement.
using (Font font2 = new Font("Arial", 10.0f))
{
    byte charset = font2.GdiCharSet;
}

&& 和 || 运算符

若要跳过不必要的比较来避免出现异常和提高性能，在执行比较时，请使用 && 代替 &，使用 || 代替 | ，如以下示例所示。

Console.Write("Enter a dividend: ");
var dividend = Convert.ToInt32(Console.ReadLine());

Console.Write("Enter a divisor: ");
var divisor = Convert.ToInt32(Console.ReadLine());

// If the divisor is 0, the second clause in the following condition
// causes a run-time error. The && operator short circuits when the
// first expression is false. That is, it does not evaluate the
// second expression. The & operator evaluates both, and causes 
// a run-time error when divisor is 0.
if ((divisor != 0) && (dividend / divisor > 0))
{
    Console.WriteLine("Quotient: {0}", dividend / divisor);
}
else
{
    Console.WriteLine("Attempted division by 0 ends up here.");
}

New 运算符

通过隐式类型使用简洁形式的对象实例，如以下声明所示。
var instance1 = new ExampleClass();
上面的行与以下声明等效。
ExampleClass instance2 = new ExampleClass();

使用对象初始值设定项来简化对象创建。

// Object initializer.
var instance3 = new ExampleClass { Name = "Desktop", ID = 37414, 
    Location = "Redmond", Age = 2.3 };

// Default constructor and assignment statements.
var instance4 = new ExampleClass();
instance4.Name = "Desktop";
instance4.ID = 37414;
instance4.Location = "Redmond";
instance4.Age = 2.3;

事件处理

如果您正在定义无需日后移除的事件处理程序，请使用 lambda 表达式。

public Form2()
{
    // You can use a lambda expression to define an event handler.this.Click += (s, e) =>
        {
            MessageBox.Show(
                ((MouseEventArgs)e).Location.ToString());
        };
}

// Using a lambda expression shortens the following traditional definition.public Form1()
{
    this.Click += new EventHandler(Form1_Click);
}

void Form1_Click(object sender, EventArgs e)
{
    MessageBox.Show(((MouseEventArgs)e).Location.ToString());
}

静态成员

使用类名称调用 static 成员：ClassName.StaticMember。不要从派生类访问在基类中定义的静态成员。

LINQ 查询

对于查询变量使用有意义的名称。下面的示例使用 seattleCustomers 代表地处西雅图的客户。

var seattleCustomers = from cust in customers
                       where cust.City == "Seattle"
                       select cust.Name;

使用别名以确保通过 Pascal 大小写格式正确设置匿名类型的属性名称的大小写。

var localDistributors =
    from customer in customers
    join distributor in distributors on customer.City equals distributor.City
    select new { Customer = customer, Distributor = distributor };

在结果中的属性名称不明确时重命名属性。例如，如果查询返回一个客户名称和一个分销商 ID，不要在结果中将它们保留为 Name 和 ID，而是将它们重命名，以阐明 Name 是客户的名称，ID 是分销商的 ID。
var localDistributors2 = from cust in customers join dist in distributors on cust.City equals dist.City select new { CustomerName = cust.Name, DistributorID = dist.ID };

使用隐式类型来声明查询变量和范围变量。

var seattleCustomers = from cust in customers
                       where cust.City == "Seattle"
                       select cust.Name;

将查询子句对齐在 from 子句下方，如前面的示例所示。

在其他查询子句前面使用 where 子句，以确保对一组经过简化和筛选的数据执行后面的查询子句。

var seattleCustomers2 = from cust in customers
                        where cust.City == "Seattle"
                        orderby cust.Name
                        select cust;

使用多个 from 子句而不是一个 join 子句来访问内部集合。例如，在 Student 对象集合中，每个对象可能都包含一个考试成绩集合。在执行下面的查询时，它将返回每一个超过 90 的分数，以及获得该分数的学生的姓氏。

// Use a compound from to access the inner sequence within each element.
var scoreQuery = from student in students
                 from score in student.Scores
                 where score > 90
                 select new { Last = student.LastName, score };

安全性

遵循代码安全维护指南中的指南。

本文链接

如何调试Memory Leak 和 Handle Leak

2011-10-10T12:35:00Z

1. Handle Leak:

A handle leak is a type of software bug that occurs when a computer program

asks for a handle to a resource but does not free the handle when it is no

longer used. If this occurs frequently or repeatedly over an extended period

of time, a large number of handles may be marked in-use and thus unavailable,

causing performance problems or a crash. The leak of handle itself is not a

big problem. The problem is that handle leak causes the leak of kernel paged

pool.

2. Memory Leak:

A memory leak is a particular type of unintentional memory consumption by a

computer program where the program fails to release memory when no longer

needed. This condition is normally the result of a bug in a program that

prevents it from freeing up memory that it no longer needs. Memory is

allocated to a program, and that program subsequently loses the ability to

access it due to program logic flaws.

//---------------------------------------------------------------------------------------------

Symptoms:

A. Handle Leaks

1. System running out of non-paged pool.

2. Failing handle allocations.

3. Degradation in system performance.

4. Excessive paging.

5. Tools like Task Manager and PerfMon show increasing handle count.

B. Memory Leaks

1. System running out of virtual memory.

2. Failing memory allocations.

3. Degradation in system performance.

4. Excessive paging.

5. Tools like Task Manager and PerfMon show increasing memory counters for

Working Set Size, Commit Size and Virtual Memory Size.

//---------------------------------------------------------------------------------------------

Causes:

A. Handle Leaks

1. The programmer mistakenly forget to close the handles. The OPEN and CLOSE

operations are not in pairs.

2. Incorrect error handling.

3. Other process inject (duplicate) the handle to the current one, who is not

aware of the injection, and thus, does not close the injected handle.

B. Memory Leaks

1. Incorrect error handling.

2. Synchronization issues.

3. Heap block caching (like BSTR etc).

C. Heap Fragmentation

1. Mixing long-term with short-term allocations.

2. Mixing small size with large size allocations.

3. Using realloc to shrink blocks.

4. Heap leaks.

/////////////////////////////////////////////////////////////////////////////

Detections and Debugging:

A. Handle Leaks

- Step1. Is It Even a Handle Leak?

The first step of investigating a potential resource leak is to confirm that

there really is one. Handle leaks can be easily detected by using Task

Manager. You can display the number of handles for a given process by

clicking the Process tab of Task Manager followed by selecting the View and

Select Columns submenu. This brings up a dialog box that displays a host of

options that Task Manager is capable of displaying. Check the Handle Count

check box, and click OK. If the Handles column shows a big number or its

value continues going up and does not go down after letting the application

sit idle for a while, the application is likely leaking handles.

In the example of LeakFileHandle, the handle count increases by 2 and doesn't

go down.

- Step2. Initial analysis

If we could identify what type of object the handle is associated with, it

might give us a better clue to the source of the leak. For example, if all

the preceding handles are thread handles, we could focus our efforts in those

parts of the code. Process Explorer is an excellent tool that has the

capability to show different handles and associated types in a process.

(http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx)

The newly created handles are highlighted for a short period. This facilitates

the detection of the leaky handles.

In the example of LeakFileHandle, Process Explorer displays the addition of

the following two handles after the execution.

File C:\Users\Jialiang Ge\AppData\Local\Temp\HLeEF15.tmp

With the information of the leaky handles, we can try to spot the culprit by

a simple code review. If the problem cannot be easily spotted, go on to the

next step.

- Step3. Using Handle Leak Detection Tools

Several tools are available to help efficiently track down handle leaks. They

are Application Verifier and !htrace.

Application Verifier

Application Verifier option "Disable invalid handle usage" or

"appverif -enable Handles". This functionality is provided by appverif on

Windows XP and later versions of OS. By activating Application Verifier,

stack trace information is saved each time the process opens a handle,

closes a handle, or references an invalid handle. It is this stack trace

information that !htrace displays.

Handle Leak Detection Tools (!htrace)

!htrace, an extension command of windbg, can help you detect where the leak

is occurring. Htrace stands for handle trace, and the basic idea behind the

command is to enable the operating system to track all calls (with associated

stack traces) that result in handles being opened and closed. When a leak has

been identified, you can then use the !htrace extension command to display

all the stack traces in the debugger. After all stack traces are shown, you

can track down sporadic handle leaks in a much easier fashion.

The general strategy for using !htrace is

1. Prior to starting the actual reproducing of the leak, enable handle

tracing (using !htrace -enable).

2. Run the reproduction and let the process handle leaks.

3. Use !htrace -diff to find the offending stacks.

Repeating steps 1-3 will give you enough information to narrow the problem

down in the code and find the leak by using code reviews.

Before !htrace can be used, Application Verifier must be activated for the

target process, and the Detect invalid handle usage option must be selected.

By activating Application Verifier, stack trace information is saved each

time the process opens a handle, closes a handle, or references an invalid

handle. It is this stack trace information that !htrace displays.

First, let's enable the handle trace:

0:000> !htrace -enable

Handle tracing enabled.

Handle tracing information snapshot successfully taken.

The -enable switch is a two-step operation. First, it enables stack tracing,

and second, it takes a snapshot of the current state of the process with

regard to handles (as indicated by the second line in the output). As soon as

stack tracing has been enabled, Windows starts recording all calls that

result in handle creation and deletion.

0:000> g

(19ec.153c): Break instruction exception - code 80000003 (first chance)

eax=7ffde000 ebx=00000000 ecx=00000000 edx=7798b412 esi=00000000 edi=00000000

eip=7794433c esp=0065fd0c ebp=0065fd38 iopl=0 nv up ei pl zr na pe nc

cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246

ntdll!DbgBreakPoint:

7794433c cc int 3

The next time you take a snapshot

(using the -snapshot option), the !htrace extension command queries the

operating system for all stack traces that result in handle creation and

deletion and displays them.

0:000> !htrace

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

Handle = 0x0000003c - OPEN

Thread ID = 0x000017ec, Process ID = 0x000017e8

0x77ca310c: ntdll!ZwDuplicateObject+0x0000000c

0x75e68ad9: KERNELBASE!DuplicateHandle+0x00000069

0x77be34e1: kernel32!DuplicateHandleStub+0x000000b3

** WARNING: Unable to verify checksum for CppResourceLeaks.exe

0x00ab1627: CppResourceLeaks!LeakFileHandle+0x00000207

0x00ab1843: CppResourceLeaks!wmain+0x00000023

0x00ab1e48: CppResourceLeaks!__tmainCRTStartup+0x000001a8

0x00ab1c8f: CppResourceLeaks!wmainCRTStartup+0x0000000f

0x77be36d6: kernel32!BaseThreadInitThunk+0x0000000e

0x77c9883c: ntdll!__RtlUserThreadStart+0x00000070

0x77c9880f: ntdll!_RtlUserThreadStart+0x0000001b

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

Handle = 0x00000038 - OPEN

Thread ID = 0x000017ec, Process ID = 0x000017e8

0x77ca2e3c: ntdll!ZwCreateFile+0x0000000c

0x75e9679f: KERNELBASE!CreateFileW+0x0000035e

0x77be51b3: kernel32!CreateFileWStub+0x00000069

0x00ab158f: CppResourceLeaks!LeakFileHandle+0x0000016f

0x00ab1843: CppResourceLeaks!wmain+0x00000023

0x00ab1e48: CppResourceLeaks!__tmainCRTStartup+0x000001a8

0x00ab1c8f: CppResourceLeaks!wmainCRTStartup+0x0000000f

0x77be36d6: kernel32!BaseThreadInitThunk+0x0000000e

0x77c9883c: ntdll!__RtlUserThreadStart+0x00000070

0x77c9880f: ntdll!_RtlUserThreadStart+0x0000001b

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

Handle = 0x00000034 - CLOSE

Thread ID = 0x000017ec, Process ID = 0x000017e8

0x77ca2d3c: ntdll!NtClose+0x0000000c

0x75e87772: KERNELBASE!GetTempFileNameW+0x00000293

0x00ab14fe: CppResourceLeaks!LeakFileHandle+0x000000de

0x00ab1843: CppResourceLeaks!wmain+0x00000023

0x00ab1e48: CppResourceLeaks!__tmainCRTStartup+0x000001a8

0x00ab1c8f: CppResourceLeaks!wmainCRTStartup+0x0000000f

0x77be36d6: kernel32!BaseThreadInitThunk+0x0000000e

0x77c9883c: ntdll!__RtlUserThreadStart+0x00000070

0x77c9880f: ntdll!_RtlUserThreadStart+0x0000001b

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

Handle = 0x00000034 - OPEN

Thread ID = 0x000017ec, Process ID = 0x000017e8

0x77ca2e3c: ntdll!ZwCreateFile+0x0000000c

0x75e9679f: KERNELBASE!CreateFileW+0x0000035e

0x75e87762: KERNELBASE!GetTempFileNameW+0x00000208

0x00ab14fe: CppResourceLeaks!LeakFileHandle+0x000000de

0x00ab1843: CppResourceLeaks!wmain+0x00000023

0x00ab1e48: CppResourceLeaks!__tmainCRTStartup+0x000001a8

0x00ab1c8f: CppResourceLeaks!wmainCRTStartup+0x0000000f

0x77be36d6: kernel32!BaseThreadInitThunk+0x0000000e

0x77c9883c: ntdll!__RtlUserThreadStart+0x00000070

0x77c9880f: ntdll!_RtlUserThreadStart+0x0000001b

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

...

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

Handle = 0x00000024 - OPEN

Thread ID = 0x000017ec, Process ID = 0x000017e8

...

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

Handle = 0x00000020 - OPEN

Thread ID = 0x000017ec, Process ID = 0x000017e8

...

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

Parsed 0xC stack traces.

Dumped 0xC stack traces.

The output of !htrace shows all stack traces recorded for openning and

closing handles. Some entries are in pairs. For example,

Handle = 0x00000034 - CLOSE

Thread ID = 0x000017ec, Process ID = 0x000017e8

...

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

Handle = 0x00000034 - OPEN

Thread ID = 0x000017ec, Process ID = 0x000017e8

...

It means that the handle 0x00000034 was opened and closed properply and was

not leaked. !htrace has a handy command option, -diff, that correlates all

paths that resulted in creation and deletion (since the last snapshot) and

reports only the stack traces that do not have a delete stack associated.

0:000> !htrace -diff

Handle tracing information snapshot successfully taken.

0xd9 new stack traces since the previous snapshot.

Ignoring handles that were already closed...

Outstanding handles opened since the previous snapshot:

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

Handle = 0x0000003c - OPEN

Thread ID = 0x000017ec, Process ID = 0x000017e8

0x77ca310c: ntdll!ZwDuplicateObject+0x0000000c

0x75e68ad9: KERNELBASE!DuplicateHandle+0x00000069

0x77be34e1: kernel32!DuplicateHandleStub+0x000000b3

0x00ab1627: CppResourceLeaks!LeakFileHandle+0x00000207

0x00ab1843: CppResourceLeaks!wmain+0x00000023

0x00ab1e48: CppResourceLeaks!__tmainCRTStartup+0x000001a8

0x00ab1c8f: CppResourceLeaks!wmainCRTStartup+0x0000000f

0x77be36d6: kernel32!BaseThreadInitThunk+0x0000000e

0x77c9883c: ntdll!__RtlUserThreadStart+0x00000070

0x77c9880f: ntdll!_RtlUserThreadStart+0x0000001b

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

Handle = 0x00000038 - OPEN

Thread ID = 0x000017ec, Process ID = 0x000017e8

0x77ca2e3c: ntdll!ZwCreateFile+0x0000000c

0x75e9679f: KERNELBASE!CreateFileW+0x0000035e

0x77be51b3: kernel32!CreateFileWStub+0x00000069

0x00ab158f: CppResourceLeaks!LeakFileHandle+0x0000016f

0x00ab1843: CppResourceLeaks!wmain+0x00000023

0x00ab1e48: CppResourceLeaks!__tmainCRTStartup+0x000001a8

0x00ab1c8f: CppResourceLeaks!wmainCRTStartup+0x0000000f

0x77be36d6: kernel32!BaseThreadInitThunk+0x0000000e

0x77c9883c: ntdll!__RtlUserThreadStart+0x00000070

0x77c9880f: ntdll!_RtlUserThreadStart+0x0000001b

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

Handle = 0x00000024 - OPEN

Thread ID = 0x000017ec, Process ID = 0x000017e8

...

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

Handle = 0x00000020 - OPEN

Thread ID = 0x000017ec, Process ID = 0x000017e8

...

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

Displayed 0x4 stack traces for outstanding handles opened since the previous

snapshot.

Therefore, our focus should be on the handles 0x3c, 0x38, 0x24, 0x20.

!handle <handle> tells the type of the handle. For example,

0:000> !handle 0x3c

Handle 3c

Type File

The call-stacks in the output of !htrace give the hint of the culprit

functions that open the leaky handles. Take the

CppResourceLeaks!LeakFileHandle function as an example:

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

Handle = 0x00000038 - OPEN

Thread ID = 0x000017ec, Process ID = 0x000017e8

0x77ca2e3c: ntdll!ZwCreateFile+0x0000000c

0x75e9679f: KERNELBASE!CreateFileW+0x0000035e

0x77be51b3: kernel32!CreateFileWStub+0x00000069

0x00ab158f: CppResourceLeaks!LeakFileHandle+0x0000016f

0x00ab1843: CppResourceLeaks!wmain+0x00000023

0x00ab1e48: CppResourceLeaks!__tmainCRTStartup+0x000001a8

0x00ab1c8f: CppResourceLeaks!wmainCRTStartup+0x0000000f

0x77be36d6: kernel32!BaseThreadInitThunk+0x0000000e

0x77c9883c: ntdll!__RtlUserThreadStart+0x00000070

0x77c9880f: ntdll!_RtlUserThreadStart+0x0000001b

One exception is that, if the call-stack looks very convoluted and does not

make any sense for the target process, the handle is likedly to be injected

(duplicated) from another process. Take the LeakInjectedHandle as an example:

0:000> !htrace -diff

Handle tracing information snapshot successfully taken.

0x1 new stack traces since the previous snapshot.

Ignoring handles that were already closed...

Outstanding handles opened since the previous snapshot:

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

Handle = 0x00000114 - OPEN

Thread ID = 0x00001700, Process ID = 0x00000d30

0x77ca310c: ntdll!ZwDuplicateObject+0x0000000c

0x75e68ad9: KERNELBASE!DuplicateHandle+0x00000069

0x77be34e1: kernel32!DuplicateHandleStub+0x000000b3

0x00101991: +0x00101991

0x00101b78: +0x00101b78

0x00102188: +0x00102188

0x00101fcf: +0x00101fcf

0x77be36d6: kernel32!BaseThreadInitThunk+0x0000000e

0x77c9883c: ntdll!__RtlUserThreadStart+0x00000070

0x77c9880f: ntdll!_RtlUserThreadStart+0x0000001b

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

Another example:

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

Handle = 0x000007D8 - OPEN

Thread ID = 0x00001700, Process ID = 0x00000d30

0x01001363: 09htarget!XcptFilter+0x00000009

0x010014D3: 09htarget!_NULL_IMPORT_DESCRIPTOR+0x000000CB

0x7C816FD7: kernel32!BaseProcessStart+0x00000023

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

The Process ID and Thread ID reported by !htrace -diff belong to the

injecting process. We can therefore find out who duplicated the handle to

the leaking proecss.

B. Memory Leaks

- Step1. Is It Even a Memory Leak?

We use Task Manager or Process Explorer to identify the potential memory

leak. First, bring up Task Manager and select the Memory Usage and Virtual

Memory Size columns in Pre-Vista machines, and the Memory - Working Set and

Memory - Commit Size columns in Post-Vista machines. Virtual memory (aka.

Commit Size or Private Bytes) indicates how much memory the process is using

overall (both in and out of physical memory), whereas the Mem Usage (aka.

Working Set) column shows how much physical memory the process is consuming.

Typically, the best indicator for memory leaks is an increase in virtual

memory size (e.g. Commmit Size) and not fluctuations in working set size.

Virtual Memmory

Private Bytes (aka. Commit Size or Virtual Memory Size)

Peak Private Bytes

Virtual Size

Page Faults

Page Fault Delta

Physical Memory

Working Set (aka. Mem Usage)

WS Private: physical memory owned by just this process

WS Shareable: physical memory that could be shared with other processes

WS Shared: shareable memory that is current shared with other processes

(It is a subset of shareable WS. It tells the possible size of memory

that will still be in use after the current process exits)

Peak Working Set

Note: Private Bytes may be bigger than Working Set Size when much virtual

memory is paged out. Private Bytes may also be smaller than Working Set Size

because the memory allocations are in pages (influencing working set size)

while the virtual memory size is in bytes which must be smaller than or equal

to one page of memory.

In the example of LeakHeapMemory, we can observe in Task Manager the

continous increase of both virtual memory size and memory usage.

- Step2. Using Memory Leak Detection Tools

Several tools are available to help efficiently track down memory leaks. They

are UMDH, LeakDiag, !address, !heap, Pageheap, and CRTDBG.

UMDH

http://support.microsoft.com/kb/268343

UMDH works by taking snapshots of the virtual memory usage of a process at

different points in time and logging them to text files. UMDH can compare the

log files taken at 2 instances of time and list the allocations that are

leaking. It requires GFLAGS "User Stack Trace Database Option" (+ust) to be

enabled in order to record the stack traces of the memory allocation requests

made by the process. Allocations and assocated stack traces in the log file

are tagged with "BackTracexxxxx". UMDH uses these tags as identifiers for

reporting leaks.

Note: UMDH tracks heap allocations only. In other words, it cannot track

allocations that are originating from non-heap-related memory activity (such

as calls to VirtualAlloc).

First, we need to enable stack traces for memory allocations. To accomplish

this, we use the gflags tool and enable "Create user mode stack trace

database" for CppResourceLeaks.exe.

gflags -i CppResourceLeaks.exe +ust

The command needs to be run as administrator. It does not enable stack

tracing for processes that are already running, but it enables stack tracing

for all future executions of CppResourceLeaks.exe. Alternatively, you can set

the flag through the GFLAGS user interface. Use the -ust option for gflags to

disable the stack tracing when you are finished debugging.

Second, we need to configure the debug symbols. One of the most important

steps to using UMDH is to make sure that you have good symbol files (.dbg or

.pdb file) to get a good stack trace. You can use the Microsoft Symbol Server

to obtain debug symbol files (http://support.microsoft.com/kb/311503/). UMDH

is capable of using dbghelp.dll to reading symbol files and resolving

addresses to symbolic function names.

Third, start CppResourceLeaks.exe and get its process ID from Task Manager.

Fourth, use UMDH to get a heap dump before the apparent leak happens with the

following command:

umdh -p:PID -f:CppResourceLeaks1.log

Now you have a complete heap dump of the CppResourceLeaks process in the

CppResourceLeaks1.log file. This file shows all of the allocations that were

made and the callstacks where the allocations were made. The log in this

state is not readable as the symbols are not resolved. UMDH can be instructed

to resolve the symbols by simulating a log comparison with an empty log,

using the command:

umdh -v CppResourceLeaks1.log > CppResourceLeaks1.txt

The resulting log contains something like:

+ 2018 ( 2018 - 0) 1 allocs BackTrace73F28

+ 1 ( 1 - 0) BackTrace73F28 allocations

ntdll!RtlAllocateHeap+00000274

kernel32!ConsoleAllocateCaptureBuffer+0000006F

kernel32!ReadConsoleInternal+0000007E

kernel32!ReadConsoleA+00000040

kernel32!ReadFileImplementation+00000075

MSVCR90D!_read_nolock+0000062C

MSVCR90D!_read+00000219

MSVCR90D!_filbuf+00000113

MSVCR90D!getc+00000208

MSVCR90D!_fgetchar+00000010

MSVCR90D!getchar+0000000A

CppResourceLeaks!LeakHeapMemory+0000003D (...\cppresourceleaks.cpp, 221)

CppResourceLeaks!wmain+00000023 (...\cppresourceleaks.cpp, 260)

CppResourceLeaks!__tmainCRTStartup+000001A8 (crtexe.c, 583)

CppResourceLeaks!wmainCRTStartup+0000000F (crtexe.c, 403)

kernel32!BaseThreadInitThunk+0000000E

ntdll!__RtlUserThreadStart+00000070

ntdll!_RtlUserThreadStart+0000001B

Fifth, while memory is leaking, take the second snapshot of the heap:

umdh -p:PID -f:CppResourceLeaks2.log

Last, use UMDH to compare the UMDH logs:

UMDH CppResourceLeaks1.log CppResourceLeaks2.log > cmp12.txt

In cmp12.txt, each log entry has the following syntax:

+ BYTES_DELTA (NEW_BYTES - OLD_BYTES) NEW_COUNT allocs BackTrace TRACEID

+ COUNT_DELTA (NEW_COUNT - OLD_COUNT) BackTrace TRACEID allocations

... stack trace ...

where:

BYTES_DELTA - increase in bytes between before and after log

NEW_BYTES - bytes in after log

OLD_BYTES - bytes in before log

COUNT_DELTA - increase in allocations between before and after log

NEW_COUNT - number of allocations in after log

OLD_COUNT - number of allocations in before log

TRACEID - decimal index of the stack trace in the trace database (can be

used to search for allocation instances in the original UMDH logs).

For example (LeakHeapMemory()),

+ 2a98c90 ( 2a98c90 - 0) 15cf4 allocs BackTrace74050

+ 15cf4 ( 15cf4 - 0) BackTrace74050 allocations

ntdll!RtlAllocateHeap+00000274

CppResourceLeaks!LeakHeapMemory+00000083 (...\cppresourceleaks.cpp, 228)

CppResourceLeaks!wmain+00000023 (...\cppresourceleaks.cpp, 260)

CppResourceLeaks!__tmainCRTStartup+000001A8 (crtexe.c, 583)

CppResourceLeaks!wmainCRTStartup+0000000F (crtexe.c, 403)

kernel32!BaseThreadInitThunk+0000000E

ntdll!__RtlUserThreadStart+00000070

ntdll!_RtlUserThreadStart+0000001B

- 2018 ( 0 - 2018) 0 allocs BackTrace73F28

- 1 ( 0 - 1) BackTrace73F28 allocations

ntdll!RtlAllocateHeap+00000274

kernel32!ConsoleAllocateCaptureBuffer+0000006F

kernel32!ReadConsoleInternal+0000007E

kernel32!ReadConsoleA+00000040

kernel32!ReadFileImplementation+00000075

MSVCR90D!_read_nolock+0000062C

MSVCR90D!_read+00000219

MSVCR90D!_filbuf+00000113

MSVCR90D!getc+00000208

MSVCR90D!_fgetchar+00000010

MSVCR90D!getchar+0000000A

CppResourceLeaks!LeakHeapMemory+0000003D (...\cppresourceleaks.cpp, 221)

CppResourceLeaks!wmain+00000023 (...\cppresourceleaks.cpp, 260)

CppResourceLeaks!__tmainCRTStartup+000001A8 (crtexe.c, 583)

CppResourceLeaks!wmainCRTStartup+0000000F (crtexe.c, 403)

kernel32!BaseThreadInitThunk+0000000E

ntdll!__RtlUserThreadStart+00000070

ntdll!_RtlUserThreadStart+0000001B

According to the comparison, the first call-stack appears for 15cf4 times,

and 2a98c90 bytes were leaked because of the LeakHeapMemory function.

!address

The !address extension command comes in very handy when you want to get a

quick overview of where the memory in your process is really located. The

command gives statistics, such as memory region usage in heaps, stack, free,

and so on.

For example (LeakHeapMemory()),

0:000> !address -summary

ProcessParametrs 00381a18 in range 00380000 0039c000

Environment 00380810 in range 00380000 0039c000

-------------------- Usage SUMMARY --------------------------

TotSize ( KB) Pct(Tots) Pct(Busy) Usage

11c4000 ( 18192) : 00.87% 02.27% : RegionUsageIsVAD

4f132000 ( 1295560) : 61.78% 00.00% : RegionUsageFree

397000 ( 3676) : 00.18% 00.46% : RegionUsageImage

200000 ( 2048) : 00.10% 00.26% : RegionUsageStack

2000 ( 8) : 00.00% 00.00% : RegionUsageTeb

2f760000 ( 777600) : 37.08% 97.01% : RegionUsageHeap

0 ( 0) : 00.00% 00.00% : RegionUsagePageHeap

1000 ( 4) : 00.00% 00.00% : RegionUsagePeb

0 ( 0) : 00.00% 00.00% : RegionUsageProcessParametrs

0 ( 0) : 00.00% 00.00% : RegionUsageEnvironmentBlock

Tot: 7fff0000 (2097088 KB) Busy: 30ebe000 (801528 KB)

-------------------- Type SUMMARY --------------------------

TotSize ( KB) Pct(Tots) Usage

4f132000 ( 1295560) : 61.78% : <free>

398000 ( 3680) : 00.18% : MEM_IMAGE

1be000 ( 1784) : 00.09% : MEM_MAPPED

30968000 ( 796064) : 37.96% : MEM_PRIVATE

-------------------- State SUMMARY --------------------------

TotSize ( KB) Pct(Tots) Usage

2f4cf000 ( 774972) : 36.95% : MEM_COMMIT

4f132000 ( 1295560) : 61.78% : MEM_FREE

19ef000 ( 26556) : 01.27% : MEM_RESERVE

Largest free region: Base 30f00000 - Size 2a970000 (697792 KB)

The column Pct(Tots) means the percentage of the entry in total virtual

memory. The column Pct(Busy) means the percentage of the entry in busy

virtual memory.

RegionUsageIsVAD - memory allocated by VirtualAlloc in VMM

RegionUsageHeap - memory allocated by heap manager

From the output

11c4000 ( 18192) : 00.87% 02.27% : RegionUsageIsVAD

2f760000 ( 777600) : 37.08% 97.01% : RegionUsageHeap

we see that most used memory is heap alloc, instead of virtual alloc, so it's

a heap memory leak.

!heap -s, !heap -a, and !heap -x -v

The !heap -s command allows you to get a detailed look at the heap summary of

the process and the suspicious heaps. Judging from the pattern of allocations

in the !heap extension command output (e.g. there are tons of blocks

allocated of same user size), chances are good that we can locate the heap

blocks that are leaked. Furthermore, by looking around at the heap block

contents (e.g. does it contain ASCII characters? does it correspond to the

address of some function / symbol?) we may see how / why the block was

allocated.

Please note that because a lot of changes happened to the heap manager in

Windows Vista and the later operating system, the allocation of heap entries

may vary. For example, the allocated block may be bigger than requested, or

the allocation granually grows in size.

To prove that this is indeed a leak, you can search for references to the

block in the process's memory space. If these potentially leaked blocks were

being used (perhaps cached), there would need to be a reference somewhere in

memory that points to that heap block. If there are no references, it means

that we definitely have a leak. The !heap -x -v allows you to search the

entire memory space of the process for the presence of a specified address.

For example (LeakHeapMemory()),

0:000> !heap -s

Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast

(k) (k) (k) (k) length blocks cont. heap

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

00150000 00000002 16384 16352 16352 2 0 1 0 0 L

00250000 00008000 64 12 12 10 1 1 0 0

00380000 00001002 64 44 44 9 2 1 0 0 L

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

The heap 00150000 occupies abnormally large memory.

0:000> !heap -a 00120000

...

00246240: 00200 . 00200 [01] - busy (1f4)

00246440: 00200 . 00200 [01] - busy (1f4)

00246640: 00200 . 00200 [01] - busy (1f4)

00246840: 00200 . 00200 [01] - busy (1f4)

00246a40: 00200 . 00200 [01] - busy (1f4)

00246c40: 00200 . 00200 [01] - busy (1f4)

00246e40: 00200 . 00200 [01] - busy (1f4)

00247040: 00200 . 00200 [01] - busy (1f4)

00247240: 00200 . 00200 [01] - busy (1f4)

...

We find a large number of blocks with the same user allocation size (1f4).

This is usually a good indicator that they are potentially leaked blocks.

The next step is to find out what these blocks actually contain. If we were

leaking memory, it would be reasonable to expect data related to our

application contained within those blocks:

0:000> db 00246c40+0x8

00246c48 41 6c 6c 2d 49 6e 2d 4f-6e 65 20 43 6f 64 65 20 All-In-One Code

00246c58 46 72 61 6d 65 77 6f 72-6b 00 00 00 00 00 00 00 Framework.......

Before we come to the conclusion that this is in fact a leak, we should

verify it by searching for references to the block in the process's memory

space.

0:000> !heap -x -v 00246c40+0x8

Entry User Heap Segment Size PrevSize Unused Flags

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

00246c40 00246c48 00150000 00150640 200 200 c busy

Search VM for address range 00246c40 - 00246e3f :

The search yielded zero results. As stated before, if a currently allocated

heap block is not referenced anywhere in memory, we can safely say that we

are leaking that block.

!heap -l

The !heap -l command causes debugger to look for leaked heap blocks. It

automates the act of dumping out all heap blocks (!heap -s) and

systematically searching for any potentially leaked blocks (!heap -x -v).

Please note that !heap -l does not work if full page heap is enabled for the

process.

For example (LeakHeapMemory()),

0:000> !heap -l

Searching the memory for potential unreachable busy blocks.

Heap 00150000

Heap 00250000

Heap 00380000

Scanning VM ...

Scanning references from 32822 busy blocks (16 MBytes) ....

Entry User Heap Segment Size PrevSize Unused Flags

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

00154640 00154648 00150000 00150000 200 200 c busy

00154840 00154848 00150000 00150000 200 200 c busy

00154a40 00154a48 00150000 00150000 200 200 c busy

00154e40 00154e48 00150000 00150000 200 200 c busy

00155040 00155048 00150000 00150000 200 200 c busy

00155240 00155248 00150000 00150000 200 200 c busy

00155640 00155648 00150000 00150000 200 200 c busy

00155840 00155848 00150000 00150000 200 200 c busy

...

29050 potential unreachable blocks were detected.

Pageheap, and !heap -p -a

After you have identified a potential leak culprit using the above !heap

commands, it would be useful to see which stack trace made the allocation to

begin with. If we had that, we could find out exactly what the code was doing

and what it was allocating.

First, we need to enable stack tracing using Application Verifier. Second,

run !heap -p -a upon the address that we thought was leaking. Not only will

we see general information about the leaked address (such as which heap it's

in and the trace ID), but we also get the full stack trace of the code that

made the allocation. From here, it is a trivial exercise to code review and

find the culprit code.

Note, while using page heap, !heap -s, !heap -a, !heap -x -v and !heap -l may

not work at all! We should find the culprit memory block and run !heap -p -a

upon it directly.

For example (LeakHeapMemory()),

0:000> !address 0b768e08

Usage: PageHeap

Base Address: 0b768000

End Address: 0b769000

Region Size: 00001000

Type: 00020000 MEM_PRIVATE

State: 00001000 MEM_COMMIT

Protect: 00000004 PAGE_READWRITE

More info: !heap -p 0x150000

More info: !heap -p -a 0xb768e08

0:000> !heap -p -a 0xb768e08

address 0b768e08 found in

_DPH_HEAP_ROOT @ 151000

in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize)

b72e700: b768e08 1f4 - b768000 2000

7c83d9aa ntdll!RtlAllocateHeap+0x00000e9f

0039fd2c vfbasics!AVrfpRtlAllocateHeap+0x000000b1

00401046 CppResourceLeaks!LeakHeapMemory+0x00000046

Not only do we see general information about the leaked address (such as

which heap it's in and the trace ID), but we also get the full stack trace of

the code that made the allocation. From here, it is a trivial exercise to

code review and find the culprit code.

CRTDBG

http://msdn.microsoft.com/en-us/library/x98tx3cf.aspx

Debug version of C Run Time Library has facilities to debug C Run Time Heap

related problems like leaks and corruption. It requires application to be

rebuilt with debug CRT.

When _DEBUG is defined the following functions call the respective _xxx_dbg()

versions which provide extra debugging capabilities: malloc, realloc, calloc,

expand, free, msize.

When _CRTDBG_MAP_ALLOC is defined the _xxx_dbg() versions of the CRT heap

functions are call directly instead of the standard versions. This enables

the _xxx_dbg() funtions to record the location (source file path & line

number) where the allocation function is being invoked. The information can

be used to identify the location in the source code where the block was

allocated.

After enabling the above flags, debug CRT heap manager can perform various

types of checking like heap corruptions and heap leaks in run-time or debug-

time:

_CrtSetDbgFlag() retrieves and modifies the behavior of the debug heap

_CrtCheckMemory() performs integrity check on memory blocks

_CrtDumpMemoryLeaks() dumps all heap blocks when memory leaks occurs

For example ((LeakCRTHeapMemory()),

First, we enable the debug heap functions, include the following statements

in the program:

#define _CRTDBG_MAP_ALLOC

#include <stdlib.h>

#include <crtdbg.h>

Note: The #include statements must be in the order shown here. If you change

the order, the functions you use may not work properly.

By including crtdbg.h, you map the malloc and free functions to their debug

versions, _malloc_dbg and _free_dbg, which keep track of memory allocation

and deallocation. This mapping occurs only in a debug build (in which _DEBUG

is defined). Release builds use the ordinary malloc and free functions.

At the end of the function LeakCRTHeapMemory, add the line

_CrtDumpMemoryLeaks();

When you run your program under the debugger, _CrtDumpMemoryLeaks displays

memory leak information in the Output window. The memory leak information

looks like this:

Detected memory leaks!

Dumping objects ->

...\cppresourceleaks.cpp(257) : {101} normal block at 0x00511F40, 500 bytes long.

Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD

Object dump complete.

//---------------------------------------------------------------------------------------------

Fixes:

A. Handle Leaks

1. Be careful to close the handles after they are created.

2. Consider employing an auto acquire/release construct. Very similar to auto

pointers, this construct allows you to acquire a handle at any given scope

and automatically free it when the auto construct goes out of scope.

B. Memory Leaks

1. Be careful that the allocation and deallocation of memory on the heap

should be paired and should target the same heap. The most common pairs are:

new - delete

malloc - free

GlobalAlloc - GlobalFree

LocalAlloc - LocalFree

CoTaskMemAlloc - CoTaskMemFree

SysAllocString - SysFreeString

2. Consider using an auto construct that automatically deletes memory when

the variable goes out of scope, such as auto_ptr in STL.

3. Consider overloading the allocation APIs used in your application. This

allows for trapping all calls to memory allocations, thereby giving you hooks

to all memory allocations performed by your applications. The allocation

hooks can then be used to track memory allocations, simulate failures in

memory allocations, and much more.

//---------------------------------------------------------------------------------------------

References:

Mario Hewardt & Daniel Pravat, Advanced Windows Debugging Ch. 9 (2007), at

Inc. This material may be distributed only subject to the terms and

conditions set forth in the Open Publication License, v1.0 or later (the

latest version is presently available at http://www.opencontent.org/openpub/).

Excerpted by Jialiang Ge, 2009.

Wiki: Handle leak

http://en.wikipedia.org/wiki/Handle_leak

Debug Tutorial Part 5: Handle Leaks

http://www.codeproject.com/KB/debug/cdbntsd5.aspx

Use !htrace to debug handle leak

http://blogs.msdn.com/junfeng/archive/2008/04/21/use-htrace-to-debug-handle-leak.aspx

Resource Leaks: Detecting, Locating, and Repairing Your Leaky GDI Code

http://msdn.microsoft.com/en-us/magazine/cc301756.aspx

Wiki: Memory leak

http://en.wikipedia.org/wiki/Memory_leak

The poor man's way of identifying memory leaks

http://blogs.msdn.com/oldnewthing/archive/2005/08/15/451752.aspx

Umdhtools.exe: How to use Umdh.exe to find memory leaks

http://support.microsoft.com/kb/268343

MSDN: Memory Leak Detection and Isolation

http://msdn.microsoft.com/en-us/library/x98tx3cf.aspx

//---------------------------------------------------------------------------------------------

本文链接

常用计算机排序算法简单总结

2011-06-20T09:33:00Z

　　计算机排序算法主要分为内排序和外排序，内排序主要指数据存储在内存中的排序，外排序通常指待排序的数据量很大，而且大部分数据存储于文件中，排序时需要读写文件的排序。通常大家讨论的都是内排序，因为内排序是外排序的根基，通常外排序过程都程序要辅助内排序。

　　最常见的内排序是冒泡排序，其时间复杂度为O(n^2), 空间复杂度为O(1)，基本上属于就地排序，而且该算法具有稳定性，在数据量不大，而且顺序基本已经排列好的情况下，该算法应该被优先考虑，其实现代码如下：

冒泡排序（Bubble Sort）

//Data swop function
void Swap(int &p,int &q)
{
    p=p^q;
    q=p^q;
    p=p^q;
}

//Bubble sort
void BuubleSort(int ArrayInput[],int nNum)
{
    int i = 0, j=0;

    for( i=0; i<nNum-1; i++ )
    {
         for(j=0; j<nNum-i-1; j++)
         {
              if(ArrayInput[j] > ArrayInput[j+1])
              {
                  Swap( ArrayInput[j], ArrayInput[j+1] );
              }
         }
    }

}
int _tmain(int argc, _TCHAR* argv[])
{
    int nNum = 10;
    int ArrayInput[] = {2,3,1,4,8,8,9,7,6,5};

    BuubleSort(ArrayInput, nNum);
    for(int i=0; i<nNum; i++)
    {
         cout << ArrayInput[i] << " ";
    }

    cout <<endl;
    return 0;
}

　　另一个比较常用的内排序是快速排序，其平均时间复杂度为O(nlgn), 最坏时间复杂度为O(n^2), 该算法为不稳定排序算法，通常对大量数据进行排序时，时间优势还是比较明显的。

快速排序（Quick Sort）

N个元素被分成3组：left, right, pivot，其中Left<=pivot<=right，所以left和right可以分别排序，而且Quick Sort中可以省去对结果组合的步骤,代码如下:

//Data swop function
void Swap(int &p,int &q)
{
    p=p^q;
    q=p^q;
    p=p^q;
}

//Partition function
int Partition(int ArrayInput[],int nLow,int nHigh)
{
    int i = 0, j=0, nTemp=0;
    i=nLow;
    j=nHigh;
    nTemp=ArrayInput[i];

    do
    {
        //From right to left
        while((ArrayInput[j]>nTemp) && (i<j))
        j--;
        if(i<j)
        Swap(ArrayInput[i++],ArrayInput[j]);

        //From left to right
        while((ArrayInput[i]<=nTemp) && (i<j))
        i++;
        if(i<j)
        Swap(ArrayInput[j--],ArrayInput[i]);
    }while(i!=j);

    ArrayInput[i]=nTemp;
    return i;
}

//Quick sort
void Quick_sort(int ArrayInput[],int nLow,int nHigh)
{
    int i = 0;
    if(nLow < nHigh)
    {
        i=Partition(ArrayInput , nLow, nHigh);
        Quick_sort(ArrayInput , nLow, i-1);
        Quick_sort(ArrayInput , i+1, nHigh);
    }
}

int _tmain(int argc, _TCHAR* argv[])
{
    int ArrayInput[] = {2,3,1,4,8,8,9,7,6,5};
    int i= 0;
    int nNum = 10;

    Quick_sort(ArrayInput, 0, nNum-1);

    for(i=0; i<nNum; i++)
    {
        cout<<ArrayInput[i]<<" ";
    }
    cout<<endl;
    return 0;
}

本文链接

C# 实现Domain Login 验证用户权限与Domain Mode读取

2011-04-22T06:23:00Z

1. Domain Login 验证用户权限

public bool ValidateDomainUser(string UserName, string Password, string Domain)
{

  bool bValid = false;

  using (PrincipalContext context = new  PrincipalContext(ContextType.Domain, Domain))
  {
       bValid = context.ValidateCredentials(UserName, Password);
  }
  return bValid;
}

2. Domain Mode读取

private void DomainModeCheck(string UserName, string Password, string Domain)
{

     DirectoryContext oContext = null;

     oContext = new DirectoryContext(DirectoryContextType.Domain, Domain, UserName, Password);
     DomainMode DM = System.DirectoryServices.ActiveDirectory.Domain.GetDomain(oContext).DomainMode;

     MessageBox.Show(DM.ToString());

}

注：本代码经过测试，运行结果正确无误，但是在Windows Server 2003 冗余Domain Servers的环境中当主Domain Server(PDC)断网的情况下，使用从Domain Server (BDC)进行权限验证，ValidateDomainUser()无法对用户权限进行验证，并且有异常抛出。

欢迎朋友们对于此问题进行讨论..

本文链接

博客园_SolidMango

《Effective STL》读书总结--关于STL 你不一定都懂的

2011总结，2012展望，生活技术都不能少

Windows程序员需要学什么

C# 语言表现树形结构—TreeView高级用法指南

一句话清晰总结协变和逆变

.Net Framework的前世今生--各个版本的新增功能

C# 编码约定

无符号数据类型 一般情况下，使用 int 而不是无符号类型。 在整个 C# 中，使用 int 很常见，并且在您使用 int 时很容易与其他库进行交互。

静态成员 使用类名称调用 static 成员：ClassName.StaticMember。 不要从派生类访问在基类中定义的静态成员。

如何调试Memory Leak 和 Handle Leak

常用计算机排序算法简单总结

C# 实现Domain Login 验证用户权限与Domain Mode读取

无符号数据类型

一般情况下，使用 int 而不是无符号类型。在整个 C# 中，使用 int 很常见，并且在您使用 int 时很容易与其他库进行交互。

静态成员

使用类名称调用 static 成员：ClassName.StaticMember。不要从派生类访问在基类中定义的静态成员。