2006年12月_hanyu1980

原创 Effective C++之26

条款26：尽可能延后变量定义式的出现时间在C中，变量定义总是在最前面。C到C++可能对此不是特别适应。在C++中，变量的定义只要出现在使用之前就可以了，并不限定在函数的开始。这里这涉及到对象生命期的情况。在函数压栈的时候，栈对象的空间都已经分配，但是对象并非就此初始化。也许有的对象的生命域在函数的执行过程中，并未触及。所以对象也没有被初始化，就好像一切都没有发生过。

2006-12-31 16:23:00 609

原创 Effective C++之25

条款25：考虑写出一个不抛出异常的Swap函数 Std中存在默认的swap函数，但这个函数是一个普适性的函数。并不代表它可以放之四海而皆准。对某些类来说，提供个性化的Swap来说是一个更好的选择。那么可以在类中提供一个member的swap。与此同时，可以特化std::swap来实现对member的swap的调用。只不过这一特化并不是放在std空间之内的。调用的时候，可以打开std

2006-12-30 18:52:00 695

原创数字表示Linux权限

LINUX文件系统中，权限的表示方式多种多样，但是对开发来说，使用数字表示比较好，例如intmkdir (constchar *path,mode_tmode = ACE_DEFAULT_DIR_PERMS)。 Mode是一个unsigned short的类型，可以用八进制数来表示，八进制以0开始。drw-r--r--，d代表目录，剩下的是rwxrwxrwx；这其中每一个可以用

2006-12-29 14:26:00 1471

原创 Effective C++之24

条款24：若所有参数皆需类型转换，请为此采用no-member函数如果某个函数的所有参数，包括this指针指向那个隐含参数都需要进行类型转换，那么no-member是必须的。对于member函数来说，this是个死结，因为这个参数在这种情况下不能进行类型转换。这里涉及到重载的问题，在这个地方尤其要注意，否则会陷入重载的深渊。C++重载有n种规则，我的原则是尽量少

2006-12-20 16:56:00 713

原创 Effective C++之23

条款23：宁以non-member、non-friend替换member函数这点为了说明什么？为了达到更好的封装性。对于non-member、non-friend函数，不存在对class的私有成员具有访问权利，这也就是说，non-member、non-friend的封装性更好。用继承来实现函数的调用实在不是好办法。

2006-12-19 18:45:00 625

原创 NMS ISDN日志跟踪

在NMS的ISDN中，可能需要跟踪一些日志反映的通道，那么如何对应呢？call reference = 01 29 flag = 000000101 message type = SETUP board 01 nai 0C group 0C 10100001 IE sending complete00000100 IE bearer capability

2006-12-19 14:50:00 872

原创 ACE应用在Linux下编译事项

使用ACE代码在Linux下进行编译的时候，有部分需要注意的事项。例如，一些g++的选项如果想写在Makefile中，如-I加入头文件搜索路径，-L加入动态库搜索路径，需要在CFLAGS宏中定义。例如：CFLAGS += -I/opt/nms/include //加入搜索路径CFLAGS += -DLINUX

2006-12-11 10:04:00 1088

原创 Effective C++之22

条款22：将成员变量声明为private 我承认在这一点上，我做的启示并不够好，原因是懒，然而往往这方面反而容易因此出现问题。最简单的是在内容修改的时候带来的代码伤害比较严重。为什么pirvate比其它权限来说存在优势？是因为private要求成员必须被封装，有了这一层的封装，可以减少对代码的伤害。

2006-12-06 14:18:00 829

原创 Effective C++之21

条款21：必须返回对象时，别妄想返回其reference 也许const reference是很不错的选择，但万事万物永远无法放之四海而皆准。Const reference也不是放在任何地方都可以的，所以需要在使用的时候仔细考量。通常返回指向local stack的reference和point并不是一个好的选择。通常作为reference返回除非有非local stack参数输入

2006-12-06 11:46:00 787

原创 Effective C++之20

条款20：宁以pass-by-reference-to-const替换pass-by-value 这样做的好处？效率高，没有多余对象生成，没有对象切片。当然也有例外的情况，内置对象和STL迭代器和函数对象也许除外。

2006-12-05 11:17:00 741

原创 Effective C++之19

条款19：设计class犹如设计type Class的设计是非常重要的问题，需要仔细考虑。如果以下问题都考虑了基本上也就可以了。1.新type的对象如何被创建和销毁？构造函数，析构函数，拷贝，以及new、delete的重载，也许都需要做，也许什么都不需要做，但是重要的是要考虑好。2.对象的初始化和对象的赋值有什么区别？这是在设计构造函数和赋值操作符需要考虑的。3.如果type用

2006-12-05 10:37:00 711

原创 Effective C++之18

条款18：让接口容易被正确使用，不易被误用接口的定义非常重要。提供给第三方的接口，你不可能知道用户会做什么，所以我们本身在写内部实现的时候，有可能假定，某些条件吻合，因为代码都是自己实现，所以可能假设代码符合那些约束条件。一旦接口提供出去，那这可就不好说了。没有人知道用户会填什么结果在里面，所以第一接口不能存在二义性，接口的行为需要保持一致。这一条款中很重要的一

2006-12-05 09:47:00 734

原创 Effective C++之17

条款17：以独立语句将newed对象置入智能指针作为C++来说，编译器的压栈顺序是自右向左。但是参数形成的执行顺序，并不是特定的，这样参数的形成上，弹性很大。如果不以独立的语句将newed对象置入智能指针，一旦异常发生，往往出现不易察觉的内存泄漏。

2006-12-04 15:04:00 681

原创 Effective C++之16

条款16：成对使用new和delete时要采取相同的形式 New和delete需要成对配合使用，否则容易出现问题，这似乎是非常简单的事情，注意一下，不必多说。

2006-12-01 18:37:00 635

原创 Effective C++之15

条款15：在资源管理类中提供对原始资源的访问资源管理类的目的是封装资源，所以对这样的类来说，需要把类透露出来。因为针对资源的接口，不一定认识你所定义的资源管理类。这时候有两种办法，一种是显式转换，一种是隐式转换。显式转换安全但不方便；隐式转换方便但不安全，实现时需要权衡利弊。

2006-12-01 18:07:00 728

原创 Effective C++之14

条款14：在资源管理类中小心coping行为 Copy的行为需要被重视是因为资源泄漏是比较容易出现的问题，这时候出现了RAII的原则。但是资源管理类的对象，存在拷贝的问题。一般来说，不处理往往容易出现问题的。处理的原则其实比较简单，根据资源的类型而定，比如说，禁止拷贝，引用计数资源共享，或者深度拷贝（比如字符串）。

2006-12-01 17:41:00 691

李永亮的专栏