不亦快斋

源代码在此，代码还是有很多问题。欢迎指正和批评，但请勿人身攻击。https://github.com/wingfiring/xirangzip包

起因:    因为工作需要,写了一个小工具,嵌入到各个项目中(这些项目都是DLL项目).然后,在这个工具可以输出一些信息到日志文件.当然,输出信息需要标明这些信息来自哪个程序模块.首先,就想到了GetModuleFileName,一查MSDN,第一个参数hModule无法提供，如果提供NULL,只能得到创建进程的那个EXE文件。又顺藤摸瓜，找到了GetModuleHandle函数。然而，问题仍然存

STRATEGY(策略)适用性：1.许多相关的类仅仅是行为有异。”策略“提供了一种用多个行为中的一个行为来配置一个类册方法。2.需要使用一个算法的不同变体。3.算法使用客户不应该知道的数据。可使用策略避免暴露复杂的、于算法有关的数据结构。4.一个类定义了多种行为，并且这些行为在这个类的操作中以多个条件语句的行署出现。将相关的条件分支移入他们各自的strategy类中以代替这些条件语句。思考：   

MEDIATOR(中介者)适用性：1.一组对象以定义良好但是复杂的方式进行通信，产生相互依赖关系混乱且难以理解。2.一个对象引用很多其他对象并且直接与这些对象通信，导致难以复用该对象。3.想定制分布在多个类中的行为，而又不想生成太多的子类思考：    MEDIATOR模式虽然是协调对象的，但是对对象的组织方式也会带来重大影响。对于一组相互作用的对象，这种相互关系是网状的，搞清楚这组对象之间的联系是

INTERPRETER(解释器)适用性：当有一个语言需要解释执行，并且你可以将语言中的句子表示为一个抽象语法树时，可使用解释器模式。思考：一个常见使用情况当然是操纵一种程序语言，例如JavaScript，Python。这个时候，我们通常使用一个脚本引擎库来实现解释器。然而，并不是所有语言都是程序语言，解释器模式更多的时候可以用来处理非程序语言，例如正则表达式。语言的规则也可以简单，也可以复杂，通常

    这是C++信徒的摩西十戒，值得将其铭刻在显示器的边缘，供C++程序员们每日膜拜。我要将其铭刻在我的blog里，铭刻在我的记忆里，直到它们成为我思维的一部分。第0条：不要拘泥于细节（了解哪些东西不应该标准化） 缩进：不必规定如何缩进，每个人遵从一个自己喜欢的规则即可。 行长：今天已经没有太大的必要限制80个字符了，当然，越有利于阅读越好。 命名：不要太严苛，

OBSERVER(观察者)适用性：1.当一个抽象模型有两个方面，其中一个方面依赖于另一个方面。将这二者封装在独立的对象中以是他们可以各自独立地改变和复用。2.当对一个对象的改变需要同时改变其他对象，而不知道具体有多少对象有待改变。3.当一个对象必须通知其他对象，而他有不能假定其他对象是谁。思考：    考虑MVC架构的一个GUI场景，当一个模型对象改变，需要在多个View中及时的更新，而模型并不关

FACTORY METHOD(工厂方法)理解:一个类需要创建某个类的实例,但是,又不知道(或者不该知道)如何创建实例时,需要工厂方法.例如一个TEMPLETE METHOD中,创建各种新实例(比如,各种文档),那么需要提供一个单一的创建接口,而将创建的实现分离出去,这种分离的创建行为,就是工厂模式.很显然,所有的创建行为,都必须提供共同的接口,创建的产品,也必须具有共同接口.这一点和抽象类厂是不一

FLYWEIGHT(享元)意图：运用共享技术有效地支持大量细粒度的对象。适用性：1.一个程序应用了大量的对象，造成很大的存储开销。2.对象的大多数状态可变为外部状态。3.如果删除对象的外部状态，那么可以用相对较少的公象对象取代很多组对象。4.应用程序不依赖于对象标识思考：    上述的适用性和别的模式中介绍的不太一样。基本上，适合使用FlyWeight模式的场景需要同时满足上述四个条件，而别的模式

     今天在vc7.1下写了一个小例子，测试一下nth_element和partial_sort,结果partial_sort表现正常，但nth_element的表现却很奇怪。     代码是这样的：vector v;for (int i = 0; i     v.push_back(i + 1);random_shuffle(v.begin(), v.end());nth_e

CHAIN OF RESPONSIBILITY(职责链)适用性：1.有多个对象可以处理统一请求，但是，那个对象处理要到运行时刻决定。2.希望在不明确接收者的情况下，向多个对象中的一个提交一个请求。3.可处理一个请求的对象集合应该被动态指定。思考：既然要向未知的接收者提交请求，那么就需要统一的提交界面，也就是说，所有接收者应该实现一个公共接口，来接收请求，当然Delegate可以改变这一状况。一个典

    这是当初发在论坛里的,可惜没有人感兴趣,渐渐的沉没了.虽说对一篇烂文章来说,沉没了反而是一件好事情,对我来说,却是学习中的一个足迹,为将来反省留个见证.老实说,这个例子过于华而不实，写的人好写，读的人却不太好读.不过其中撰写复杂lambda的总结，基本上还是可用的。    lambda库固然是非凡的，但是，Boost.Spirit.Phoenix更是锋利，也许下一次，我会研究研究Phoen

from: http://blog.youkuaiyun.com/goodboy1881/archive/2006/03/27/640004.aspx  

    分析了公司的一个项目代码，结果令我非常沮丧。分析的这个项目大约有500个文件， 并不很大。我承认，这个项目的程序员都是训练有素的，然而，都是C语言的训练有素，不是C++的。    我们为什么选择C++作为一个软件项目的开发语言？我想，决不是因为C++更复杂华丽，也不是因为C++支持OO，OB，也决不是因为C++是支持GP的最佳选择。论二进制兼容性，C++不如C；论OO支持的干净利落，C++

    我们要想写文章,最起码,要能认识足够多的字.但是，更重要的，是要知道我们想说什么。这两个方面都是不可或缺的。那么，是不是要等到认识了所有的字才能写文章？当然也不是。如果每写几个字就需要查字典恐怕也写不好文章--思路都被打断了。首先，我们应该在文字上自由了，然后就可以畅快地表达自己的思想、观点、感受，偶尔一两个成语典故需要查一查字典也无伤大雅。    就这方面来说，写文章和写程序是极其相似的

  《Imperfect C++》中展示了一种叫“螺栓”的技术，然而，这本书中的讨论并不足够深入。当然，我也相信Matthew是故意的，从而让我们这些“三道贩子”(Matthew自称是二道贩子)也能够获得一点点成就感。 非典型秃子http://blog.youkuaiyun.com/wingfiring/  考虑这样一个接口设计：    struct IRefCount;    struct IReade

本文谢绝转载 http://www.weibo.com/0x2b    Protein的性能瓶颈主要是在runtime，而runtime是基于FBX来写的。FBX已经停止开发，而且改动代价太高，因此，美国那边打算把把FBX从runtime中去掉。这是一个大工程。当时Protein的新经理M也刚来不久，我们都有点担心资源不够。这时，美国的架构师也忙于新的项目，也没时间给出Protein的新设

本文谢绝转载 http://www.weibo.com/0x2b因为最初我只是想证明我的那个可扩展的类型系统，因此我给ADPLite改了个名字，叫“息壤”，喻意类型系统会像息壤一样，能够生长。到11年夏天的时候，息壤已经有了一些东西：    1.DBC库--这个是以前的工作。除了pre-condition，post-condition，invariant三个宏之外，允许用户自定义和设置

本文谢绝转载 http://www.weibo.com/0x2b梦断代码--一个程序员的自白(五)    O同事给我的回复中，除了强调控制内存使用外，原来还指望通过扩展string的实现来支持数组。他真是太高估我的结果了。但是同时，他又提出了一些让我难以理解和接受的内容：不喜欢暴露新的接口，数据必须保持为char*形态，模板不能跨边界分配和销毁。站在他预设的，str

本文谢绝转载 http://www.weibo.com/0x2b    大约是各方面对ADP的反响都不大好，ADP要想推销自己，必须找到新出路。最终，目标锁定到Protein，让Protein通过ADP来存储材质包。对于Protein项目，我至今也不知道最初的立项缘由。Protein后来被定位成一个内容（材质）管理库，为公司的所有产品提供统一的材质管理。最早，Protein是基于FBX(一

本文谢绝转载梦断代码--一个程序员的自白 (四）   一个周末过去，对于我所回复的，如何在运行时存储字符串的问题的解决方案，O也有了回应。O对我的方案非常不满，认为我的方案是他之前就考虑过的，我完全没有解决他所担心的问题。应该说，这次合作不愉快，我也是有很大责任的，主要是在沟通方面。在之前的一周时间内，我除了问他问题，他回答，就没有真正双向的交流。他所担心的问题之一是内存碎片化，而我对

本文谢绝转载 http://www.weibo.com/0x2bPS：这一章水的比较狠，就当看盗版网络小说了吧。见谅。   我对公司有一个很不满意的地方，就是缺乏像样的职业培训。我来到这里之后一直是传授东西给别人--当然我对此并不抗拒，还很乐意--自身的水平却没什么提高。于是我打算还是学点东西。我把业余的时间都拿来玩Linux和开发板。我工作中接触的第一个操作系统就是Unix，

本文谢绝转载梦断代码--一个程序员的自白 (二）    AIRMax是一个庞大的项目计划，需要3～5年的时间来完成。这个缩写是取公司的主打产品首字母和特征单词组成的，也意味着这个项目要影响到所有这些支柱产品。公司的这些产品都是不同领域的设计软件。这个项目计划在三个方面做资源整合，即为所有产品提供统一的程序库或者框架：程序外观(GUI)，渲染（主要是3D引擎），和文件格式（保存设计成果）

本文谢绝转载梦断代码--一个程序员的自白 (三）    "程序员是工程师吗"？这是我在大约10年前初次接触敏捷方法时，让我有醍醐灌顶之感的一个问题。那个时候，称呼程序员为码农，IT民工，吃青春饭的，周围充斥着三十岁后能不能做技术的质疑。这个问题让我真正想明白自己从事的是怎样的一个职业。已经忘了最初在哪里看到这篇文章的，很幸运，我今天在Robert Martin的那本《敏捷软件开发》

转载请注明出处:　http://blog.youkuaiyun.com/wingfiring某些C/C++编程的书中,曾经提到如何判断指针是否为空的问题.很显然,if (p == NULL), if (p == 0) 和if(p),都能够完成这一任务,差别在于可读性方面.我们分别加以讨论. 1. if (p == NULL) 相当多的文章建议采用,他们中的部分人甚至认为,其他做法都是错误的.这个形式一个变种是

项目中看到这样的代码：m_optimizedPolygons = false；if (gdi_compatible && (true == gdi_compatible->value().as_boolean()))        m_optimizedPolygons = true;看到什么问题了吗？有没有人吐血身亡？哦，对不起，朋友，帮忙打个１２０．．．．．．无数Ｃ++的文章和书籍----至少

               人们常说，模式是解决方案的重用，是经验的重用。借助已有的经验和典范，可以帮助我们少走弯路，还可以在更高的语言层次描述系统和相互沟通。然而，模式本身是如此的抽象，对于模式的理解和运用很大程度上依赖于程序员个人或团队的经验和技艺。模式是很好的东西，然而传授模式却是如此的困难。模式的适用性是一个非常重要的指标，错误地运用模式，将会加剧表达的不自然，恶化代码的可读性

错误和异常处理参考关于编写健壮的通用组件的一些问题，下面的论文给出了很好的介绍:D. Abrahams: ``Exception Safety in Generic Components, 由M. Jazayeri, R. Loos, D. Musser (eds.): Generic Programming, Proc. of a Dagstuhl Seminar, Lecture

FACADE（外观）适用性：1.需要为一个复杂子系统提供一个简单接口时，为子系统提供一个简单的外观。2.客户程序与抽象类的实现之间存在很大的依赖性3.当需要构建一个层次结构的子系统时，使用FACADE来定义子系统中每层的入口点。思考：    关于第一点，好处是明显的，它降低了客户的学习成本。但是，一般而言，如果这个子系统是一个定制的子系统，可能直接提供一个简单接口更省事。如果这个子系统来是已经实现

COMPOSITE(组合)适用性：1.想表示对象的部分整体层次结构2.希望用户忽略组合对象和单个对象的不同。思考：组合模式的所有组件应该具备同一个接口。一直感觉，这种组合是一种递归组合的概念。所有的组件，按照树的结构组织起来，树的叶结点行为可能和中间结点的行为并不一致，这看上去违背了Liskov原则，似乎是一个容易引起迷惑的地方。树的叶结点可能并不能增加子结点，删除子结点的行为也可能失败。而一个中

December 5, 2005 - Version 1.33.1Updated Libraries Any Library: Cast to reference types introduced in 1.33.0 is now documented on any_cast

po::variables_map vm;po::store(po::parse_command_line(ac, av, desc), vm);po::notify(vm); 在store之后，一定要notify,我老是忘记：（还有，vm其实就是是一个map,可以用迭代器来访问成员的。可以用这个来拆分命令行，而不必用splite或者stringstream来处理。vector args

支持右值构造。在写复合语句－－嗯，就是Meyers在《effective stl》里面说的那种write only的代码时候－－常常发生这种情况。现在好了，是不是我可以写更多的write only的代码了？并且，考虑把所有的T& 替换成T&&?^_^Rvalue constructors• Often we copy a value just before it isdestroyed● Exam

在VC上尝试输入输出宽字符时发现，wcout.imbue调用，居然会影响wcin wstring t; wcin >> t; //没问题 wcout.imbue(locale("chs")); wcin >> t; //键入中文时有问题而对wclog, wcerr调用imbue,则不对cin产生影响。也就是说，wcout和wcin之间有奇特的关系。对wcin调用imbue,不会影响wcout,反过

    C++当中常常需要一个全局唯一的对象实例，这时候，我们就会想到单件模式。如何实现这一模式？全局变量当然是一个简单可行的方法，然而，这太丑陋。嗯，其实，丑陋倒也罢了，最严重的是它将引诱程序员滥用全局变量，这将导致维护的灾难。    既然全局变量是可能有害的，那么，我们我们把它隐藏一下，放到某个类当中去，作为类的静态数据成员。这看上去不错，我也这么认为。当我们只是简单的需要一个全局对象时，这很

更新说明：修改了借口，增加了对smart_ptr的支持。最近需要一个C++delegate的实现，比较接近C#的delegate的用法。翻遍了boost，虽然有相近的东西，但是，始终使用起来问题多多：function:的绑定方式倒也可以接受，成员函数调用的方式实在不爽。而且，同样的函数原型，native和member对应的function类型不同，不同class的相同原型的member funct

    让我们的一切从代码开始吧,简单起见，代码省略std名字空间：class MyObject {    object_id obj_id_;    class_id  class_id_;    map properties_;    static const type_dict& getDict();...};    这是个从实际的项目中整理出来的代码，简单的说明一下：properties存

C++写入rds->Open("tb_test1", conn.GetInterfacePtr() , adOpenDynamic, adLockOptimistic, adCmdTable);rds->AddNew();rds->Fields->Item[1L]->AppendChunk(_variant_t(strfile.c_str()));rds->Update(); as

这是一段引用计数指针的代码，目标是一个轻量级的、高效率的实现，避免通常实现中的频繁的new/delete引用计数的存储空间。 一些说明： Q:为什么在ref_count的release中delete对象，而不是让外部的ref_count_ptr来释放对象？ A:将对象的销毁放到比较高的层次上，从而使得程序员更容易控制对象的销毁策略，看上去是非常有诱惑力的。但是，问题在于，我们使用ref_count

忘记出处了，留着自己用的。 void TWakeUpOnLanForm:: WakeRemoteComputer(AnsiString IPAddress,unsigned char * MacAddress){        unsigned char SendBuf[102];        for( int i = 0; i         {                SendBuf[