随陆无武-CSDN博客

原创在MSYS2和MinGW-W64编译GCC6.3

尝试自己动手在Windows上编译GCC6.3。以前了解过Cygwin和MinGW，这是Windows上编译Linux程序的典型配置。但是这些工具都古老了，这里尝试使用MSYS2 + MinGW-W64结合来编译GCC6.3。本人亲测，依据如下步骤保证能够编译通过：1). 到{http:\\www.msys2.org\}下载MSYS2，我下载的版本是{msys2-x86_64-20161025

2017-07-12 22:42:06 5403 1

原创输出编译器预处理器的中间文件

问题描述这几天在尝试阅读一些OpenJDK的源代码，但是发现Source Insight工具无法跳转到某些些函数，类型的定义上去。例如：JNI_ENTRY(void, jni_SetStaticObjectField(JNIEnv *env, jclass clazz, jfieldID fieldID, jobject value)) JNIWrapper("SetStaticO

2015-10-04 11:55:46 569

原创设计模式（25） - 行为型模式总结

行为型模式关注于对象之间在行为方面的交互。可以从如下角度来解析各种行为模式：和对象状态更新相关的模式备忘录模式关注于对象状态的备份与恢复，但不破坏对象的封装性。Memento由对象自行创建，由客户保持；客户在需要的时候利用 Memento来恢复对象状态状态模式描述了对象状态的修改如何导致对象行为的改变观察者模式引入订阅，发布机制来通知观察者关于被观察对象状态的更新；这种

2015-08-01 11:39:55 342

原创设计模式（24） - 中介者模式

问题描述在一个系统中存在多个实体对象，这些实体对象之间存在交互关系。例如：实体A状态更新会导致实体B自动得到更新，并依据实体A的变化采取相应的动作。把实体对象之间的交互关心设计到每个实体对象中，会引入实体类之间的依赖关系，从而限制了实体类的可重用性。中介者模式引入一个单独的中介者对象来管理实体对象之间的交互关系。每个实体对象只和中介者对象交互，这保证了实体对象之间的独立性。中介者模式

2015-08-01 11:32:42 298

原创设计模式（23） - 命令模式

问题描述一个消息的发送者对象向消息的接收者发送消息，发送者如果保持接收者的信息，即可完成消息的投递。但是这种方式把消息的发送者和接收者直接绑定在一起，让消息的发送者依赖于消息的接收者。命令模式解除了消息发送者对于消息接收者的依赖。命令模式如图所示，命令模式引入了一个间接层即Command对象来隔离消息发送者Invoker对象和消息的接收者对象Receiver。客户把一个消息接收者对

2015-08-01 11:26:56 203

原创设计模式（22） - 访问者模式

问题描述集合的节点元素类型相对稳定，但是，在遍历集合各个节点元素的时候，针对不同类型节点元素的访问操作各不相同；并且将来更可能会添加新的访问操作。如果把这些访问操作实现成节点元素的方法，那么这种访问方法就成为节点类型的一个变化点。如何避免对节点元素的修改而又支持新的节点方法呢？访问者模式！访问者模式如图所示，由于系统中元素节点类型相对稳定(例如ConcreteElementA &

2015-08-01 11:20:41 207

原创设计模式（21） - 责任链模式

问题描述让集合对象中的多个节点对象都有可能处理某个请求(消息)，保证请求的发送者对请求的接收者透明。责任链模式如图所示，责任链模式把多个对象(即ConcreteHandler1, ConcreteHandler2)组织为一个链式结构，让请求延着该链表传递，直到某个对象处理该请求。客户只需要向该链式结构投递一个请求/消息而不必关心该请求被哪个接收Handler处理。/

2015-08-01 11:15:54 221

原创设计模式（20） - 迭代器模式

问题描述在集合对象(例如链表)的顺序访问中，集合对象需要提供一种访问下一个节点的方法，这可能会暴露集合对象的内在结构。迭代器模式在隐藏集合对象内部结构的同时，提供遍历集合对象元素的方法。迭代器模式如图所示，迭代器模式定义一个抽象的Iterator接口对象来支持集合对象的遍历；Aggreate类定义了一个工厂方法来创建本集合对象特定的Iterator对象。ConcreteIterat

2015-08-01 11:05:48 214

原创设计模式（19） - 策略模式

问题描述一个类的某个方法，可能存在多种不同的逻辑实现(即算法)，并且只有该类的客户才能确定使用哪个算法。一种解决这个问题的办法是：将该方法定义为一个接口(虚函数)，创建该类的不同子类，重载该接口来实现不同的算法；客户选择不同的子类来选取不同的算法。但是，仅仅因为一个方法而通过继承创建子类，会产生多个较大的类；也不利于这些算法的重用。策略模式则将该方法封装成一个独立的算法类，由算法类的子类来实现

2015-08-01 11:02:42 280

原创设计模式（18） - 模板方法模式

问题描述定义一个算法框架，容许该算法框架中某些操作可以被扩展。模板方法模式利用多态特征来定义一个算法框架，通过子类化得到不同的行为。模板方法模式如图所示，一个抽象基类AbstractClass定义了一个模板方法 TemplateMethod()，该方法调度一些抽象接口(i.e. 虚函数，例如 VirtualOperation1())来定义一个算法框架。依据C++多态特征，Conc

2015-08-01 10:57:16 285

原创设计模式（17） - 观察者模式

问题描述当对象的状态发生变化的时候，某些关注该对象的对象可能希望得到通知并调整自己的状态。例如一个表格数据对象有不同的图形呈现，当数据发生变化的时候，这些图形对象希望得到通知并重新绘制。观察者模式支持这种通知但确保对象和对象的观察者透明。观察者模式如图所示，ConcreteObserver对象对ConcreteEntity的状态m_entityState感兴趣。ConcreteOb

2015-08-01 10:53:36 240

原创设计模式（16） - 状态模式

问题描述存在某个对象的方法，其行为模式依赖于对象的内部状态；这些内部状态更可能影响多个对象方法。这些对象方法的代码结构通常是：依据不同的内部状态，执行不同的操作。这种状态判断分散在多个方法中，损伤了代码的可理解性和可维护性。状态模式把这些方法抽象成一个 State抽象类，为对象的不同内部状态实现不同的State具体类。当对象状态发生变化的时候，切换不同的State具体类，对象即可呈现不同的表现

2015-08-01 10:41:59 177

原创设计模式（15） - 备忘录模式

问题描述有时候程序需要备份某个对象的当前状态，并在适当的时机恢复对象的状态。对象的状态通常包含了对象的私有信息，备份对象状态可能会破坏对象的封装性。备忘录模式在不破坏对象封装性的前提下，实现对象内部状态的备份和恢复。备忘录模式如图所示，备忘录模式描述了如何在不破坏封装性的前提下，为对象内部状态提供备份和恢复的。首先为对象Originator创建一个备忘录对象Memento来保持对象

2015-08-01 10:36:42 349

原创设计模式 (14) - 结构型模式总结

结构型模式关注于“如何组织对象”形成一个合理的对象结构。我们知道对象都具有属性和方法：Flyweight/享元模式优化属性的定义来节约内存开销。享元模式把属性分解为“内在属性”和“外部属性”。“内部属性”即“本质属性”的数量相对少并且变化较少，“外部属性”则由客户端维护并以参数的形式通知Flyweight对象。这样的分解方法，使Flyweight对象的内存需求相对较小。享元模式通过抽象工厂

2015-07-26 22:17:07 313

原创设计模式 (13) - 桥接模式

问题描述当一个抽象有多种不同的实现方式的时候，继承是一种典型的方法；但是这种方式让抽象和实现静态绑定。如何让一个面向客户的抽象接口，和实现该抽象接口的具体实现相隔离？如何让抽象接口和实现该抽象的实现接口独立变化？桥接模式让抽象接口及其具体实现解耦。桥接模式如图所示，桥接模式定义了两个抽象接口：Abstraction和Implementor接口。Abstraction接口为客户提供使

2015-07-26 22:14:54 204

原创设计模式 (12) - 装饰模式

问题描述通过继承来扩展父类的功能和职责，C++程序设计的基本手法。继承以一种静态的方式为类型添加职责。装饰模式则是动态的为对象添加功能。尤其是当类的定义被隐藏，或者类定义无法用于生成子类的时候，装饰模式是一种适当的方法来扩展该类。装饰模式如图所示，装饰对象Decorator保持和被装饰对象Object完全相同的接口。Decorator构造函数将被装饰对象Object作为参数并保存在

2015-07-26 22:14:11 253

原创设计模式 (11) - 适配器模式

问题描述为了重用一个已经存在的模块，但是接口不兼容，如何让两个功能相似但是接口不兼容的代码能够一起工作呢？适配器模式适配器模式提出两种方式来适配两个不兼容的接口：类适配器采用多重继承的方式，用一个接口来实现另外一个接口；对象适配器则将一个对象的实例作为另外一个对象的组成部分来实现一个接口。下图描述了对象适配器模式是如何工作的：Adaptor对象实现了一个Target接口，其内部包含

2015-07-26 22:13:48 207

原创设计模式 (10) - 代理模式

问题描述在某些情况下，客户软件需要间接访问一个对象，例如：所访问对象不在相同的地址空间，例如在另外一个进程，在另外一台机器上等；所访问对象的创建开销很大，程序在真正需要的时候才创建该对象；所访问对象由于安全因素而不能被直接访问，必须在实施正确的安全策略后才容许访问；智能引用取代简单的指针，为对象访问附加一些操作，例如引用计数；代理模式为对象访问提供一种间接性，客户不需要关注上面

2015-07-26 22:11:48 203

原创设计模式 (9) - 外观模式

问题描述划分一个系统成为多个子系统，是设计一个复杂系统，简化系统设计的典型方法。但是，如果直接向客户暴露这些子系统接口，不利于系统设计的独立变化，更可能把子系统之间的交互关系直接暴露给客户，从而导致客户逻辑的复杂性。外观模式为系统提供一套相对简洁的接口，降低客户逻辑和系统具体设计的依赖性/耦合性；也让系统设计独立于客户而扩展变化成为可能。外观模式如图所示，外观模式的核心要点是：为系

2015-07-26 22:10:14 194

原创设计模式 (8) - Composite模式

问题描述程序有时候需要同时处理叶子节点对象及其容器对象。普遍的做法是：程序依据对象类型调用不同的方法来实现逻辑控制。这种方法区别对待容器对象和节点对象，让代码显得复杂臃肿。Composite模式让容器对象和节点对象提供一致的接口，从而对客户隐藏对象类型的差异性。Composite模式如图所示，Component接口定义了节点对象(即Leaf)和容器对象(即Composite)的公共

2015-07-26 22:09:52 299

原创设计模式 (7) - Flyweight/享元模式

问题描述一个系统中可能创建某类型的大量实例，有什么方法可以节约内存开销呢？享元模式如图所示，享元模式划分对象的内部状态和外部状态，外部状态和对象的运行上下文相关；把外部状态封装成为对象的接口参数传递到对象的方法调用中。对象方法依据对象的内部状态和参数所代表的外部状态来执行相关逻辑。由于外部状态由客户计算或者保持，而内部状态又相对稳定，因此改对象的实例个数相对较少。这种对象属性的划分

2015-07-26 22:05:31 256

原创设计模式(6) - 创建型模式总结

创建对象最直接的方法就是利用C++提供的构造函数，这种方法的缺点是让代码绑定了具体的类型；一旦该具体类型需要被替换为新的类型，那么程序逻辑就不得不修改；更糟糕的是，可能需要到处修改这样的代码。Open/Close原则的一个要旨是要避免这种修改！如前所述，所有的创建型设计模式解决这个问题的方案都是：基于一个稳定的接口来创建对象。工厂方法模式定义一个抽象接口，由该接口的子类来决定所创建对象的具

2015-07-21 23:44:44 346

原创设计模式(5) - 单件模式

问题描述某些类型(例如前面介绍的工厂类)在一个系统中只能出现一份实例。《More Effective C++》条款26详细的讨论一些可能的方法。那么，单件模式给我们带来了什么呢？单件模式如图所示，单件模式提供的解决方案是：让类自己保存自己的一份实例(m_instance)，提供一个访问该实例的方法(Instance())，并限制其他途径来创建另外一个实例。讨论

2015-07-12 21:28:58 270

原创设计模式(4) - Builder模式

问题描述一个复杂对象由不同的子部件构成，依据不同的上下文，该复杂对象的子部件可能有不同的具体类型(从用户来看，该复杂对象有不同的外在表现)。如何通过一个相同的构造过程，产生这种不同的复杂对象？也可以说：如何隔离对象的构造过程和对象的具体表现形式？Builder模式如图所示，Builder类定义了构造一个复杂对象内部各个子部件的抽象接口(即多个不同的BuildPart()接口)，Di

2015-07-12 21:27:33 211

原创设计模式(3) - 原型模式

问题描述无论工厂方法模式，或者是抽象工厂模式，客户端程序在创建一个对象的时候，都依赖于一个具体的工厂类。本质上来说，客户程序和这些具体的工厂类紧紧的绑死了。但是，某些程序(例如框架程序)可能无法访问这些具体的工厂类，也可能需要一种动态的，可以配置的方式来创建对象。原型模式通过一个原型管理器来提供这种动态性，通过复制/克隆一个已经存在的对象来解除对于工厂类的依赖。原型模式如图所示，P

2015-07-12 21:19:16 284

原创设计模式(2) - 抽象工厂

问题描述一个系统通常由多个相互关联的类/接口构成。如果这些相关类/接口存在不同版本的实现方式，如何保证这些不同版本的相关类能够配套工作？当然可以用硬编码的方式来保证，但是当这些相关类数目众多，引用方式庞杂，硬编码的方式并不容易，也不方便维护。抽象工厂模式提供一种直截了当的方式来确保这种相关性(类之间的配套关系)；通过一个具体的工厂类，程序员能够方便的选择一组配套的接口对象来配置该系统。

2015-07-12 20:56:48 257

原创设计模式(1) - 工厂方法

问题描述一个接口（如下图的Product）可能有多种实现方式。程序逻辑在实例化这种类型/接口的具体类(如下图的ConcreteProduct)的时候，如果直接使用{new ConcreteProduct()}的方式来撰写；当需求变更的时候，程序需要使用另外一个子类（例如SubProduct）来替换该类的时候，所有使用{new ConcreteProduct()}的地方都需要修改。这种代码的特征

2015-07-05 22:33:59 266

程序人生