自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+

李永亮的专栏

设计改变中国!

  • 博客(15)
  • 收藏
  • 关注

原创 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 673

原创 Effective C++之45

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

2007-02-25 20:41:00 570

原创 Effective C++之44

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

2007-02-25 20:35:00 612

原创 Effective C++之43

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

2007-02-25 20:33:00 584

原创 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 654

原创 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

空空如也

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除