2007年02月_hanyu1980

原创 Effective C++之48

条款48：认识template元编程将工作从运行期转移到编译期是非常有意义的事情，这样会有效的提高系统运行效率，还可以使错误暴露的更早。TMP还可以用于实现policies的代码。在设计模式中，更是在template等类型中有模板和运行期多态两种实现。

2007-02-25 20:49:00 656

原创 Effective C++之47

条款47：请使用traits classes表现类型信息 traits是模板元编程的常用技法，用于萃取出类型。traits被广泛应用于STL中，例如value_type，在使用重载函数的方法，可以经由traits实现对函数执行的条件判断，就好像写了if...else…。

2007-02-25 20:47:00 693

原创 Effective C++之46

条款46：需要类型转换的时候请为模板定义非成员函数参考24条款，在使用类型转换的时候需要使用non-member函数，但在template中，这里可能存在一点问题，原因是在模板的参数推导的时候会遇到问题。解决这个问题的方式是将这个non-member函数声明成类的friend函数，这样在参数推导的时候就能解决这个问题。

2007-02-25 20:42:00 680

原创 Effective C++之45

条款45：运用成员函数模板接受所有兼容类型对shared_ptr和shared_ptr来说，这是完全不同的两种类型。为了避免这样的可能带来的不便，需要在程序做兼容。示例如下：templateclass shared_ptr{public: shared_ptr(shared_ptr const & r)//拷贝构造函数

2007-02-25 20:41:00 575

原创 Effective C++之44

条款44：将与参数无关的代码抽离templates Template在编译期生成多个classes和多个函数，所以任何template代码都不该与某个造成膨胀的template参数产生相依关系。也就是说，在编译期，编译器完成对template代码的具现化，此时容易产生生成代码的膨胀。因非类型模板参数造成的代码膨胀，往往可以消除，方式是以函数成员或者class成员变量替换templa

2007-02-25 20:35:00 613

原创 Effective C++之43

条款43：学习处理模板化基类内的名称关于这一条，我将Meyers的代码放在VC6中编译，并未出现所谓的行为实效。我想VC6本来对模板的支持有限，所以这种情况下，只能看看这条款上的描述了。从VC6的效果来看，当特化的时候问题依然会出现，但仅在出现不同特化的时候出现。本条款问题产生于在template中，原有继承上的特性并不能完全生效。在继承的时候调用基类函数的时

2007-02-25 20:33:00 585

原创 Effective C++之42

条款42：了解typename的双重意义通常对template中声明模板元时class的使用和typename并无不同。但在标识从属类型名称的时候需要用到typename，虽然这并不是常用的用法。当然这存在两个例外，base class list和mem.init.list。

2007-02-25 20:30:00 571

原创 Effective C++之41

条款41：了解隐式接口和编译期多态我们通常使用的多态一般来说就是运行期多态，一般使用虚函数来达到多态的目的。多数人并不是template高手，所以在使用template的情况相对来说还是比较少的。我常常觉得C++的内涵如此之多，以至于人们在使用他的时候，究竟使用了其中的多少。编译期多态，也就是利用template来编译完成时，就完成了多态的计算。Template

2007-02-25 20:29:00 641

原创 Effective C++之38

条款38：通过复合塑模出has-a或“根据某物实现出” 对于该点条款似乎是在说，继承并不是最好的手段。我对此表示同意。事实上我认为如果可以不用继承，就不用继承，继承远没有想象的那么好。如果可以的话，Composition的意义非比寻常。事实上这才是构造对象的基本办法之一。那么在继承关系并不十分明确的时候，建议还是使用组合方式。

2007-02-09 18:16:00 712

原创 Effective C++之37

条款37：绝不重新定义继承而来的缺省参数值这是我以前所不知道的，在读这本书的时候所涉及到的知识点，还没有遇到过什么新东西，然后越往后越要知道C++不过是种工具，如果工具用好了，不过是消除了工作可能遇到的障碍。但这并不代表C++好了，其他所有的东西都没有问题了。具体的做事情的办法是和工具无关的。这件事情C++可以做好，并不代表C做不好，java也可以的。在这里C+

2007-02-09 18:05:00 657

原创 Effective C++之35

条款35：考虑virtual函数以外的其他选择 NVI流，这个东西有点让我联想到Warcraft的Sky流，这种流派主张将虚函数设计成私有，而所有的接口都是public函数。这里面可能遇到的问题是显式调用基类的函数的问题，所以在遇到这种情况下，可以适当放宽权限的控制，protected函数应该可以接受吧。使用函数指针实现策略。这可是比较有意思的事情了，因为我在自己

2007-02-09 16:58:00 590

原创 Effective C++之34

条款34：区分接口继承和实现继承成员函数的接口总是被继承，前提不存在隐藏，详见前一章。基类中声明纯虚函数，目的只是为了让Derived Class只继承函数接口。声明Impure virtual函数的目的是为了继承函数接口和缺省实现。非虚函数的作用是继承接口，和强制接受实现。

2007-02-09 15:55:00 653

原创 Effective C++之33

条款33：避免遮掩继承而来的名称这其实就是一个隐藏的问题。在基类可能存在一些函数，一旦继承了存在同样的函数，基类的函数就被隐藏了，不要指望所谓的重载，在这样情况下重载是不生效的。比较有效的办法是使用using或者生成转交函数。

2007-02-09 14:54:00 652

原创 Effective C++之32

条款32：确定你的public继承塑模出is-a关系不要单纯为了使用某些类的接口而使用继承，更不要留恋蝇头小利，公有继承只意味着一件事情就是”is－a”关系。继承是件美丽的事情，前提是接口定义的完善。通常在自然语音中，定义是不完备和不严密的。所以在变成逻辑语言描述的时候就需要严密的考量。

2007-02-09 10:47:00 605

原创 Effective C++之31

条款31：将文件间的编译依存关系降至最低经常出现这样的问题，在头文件里面修改了一点点东西，然后重新的编译，然后就可以慢慢喝茶了。这样的事情当然不希望出现了。如果看看ACE就知道高手是怎么做的了。ACE上很多的类都提供了Imp类型，这用托管的方式就是想把实现屏蔽起来。这样可能存在一些原则需要注意：如果可以使用指针或者引用，就不需要用对象，因为指针和引用的大小是确定的，但对象就不

2007-02-01 16:50:00 720

李永亮的专栏