2006年03月_hanyu1980

原创 Exceptional C++ Style之25

第25条再论内联我个人的习惯是写一大堆private的内联函数，难道这也有错么？但是编译器并不是那样的听话，写了inline就内联，不写就不内联。Inline关键字可能对于很多编译器来说，means建议。跨模块内联，这可是新技术，但是已经有编译器支持这一特性，这就需要连接期做一点工作了。安装时，很新颖，但是可能CLR、JVM真的支持这一特性，对于VC6这可能就不是这样了。运行期

2006-03-30 19:00:00 854

原创 Exceptional C++ Style之24

第24条常量优化 Const的主要作用在代码安全性上，如果是性能优化的话，不妨用const引用。Const直接使用很少能直接改善性能，例外就是对象本身存在对const的优化。

2006-03-30 18:35:00 737

原创 Exceptional C++ Style之23

第23条进行new的操作，也许会抛出异常之二：内存管理中的实际问题我从来没有尝试过nothrow new，因为这个地方并不是问题的关键，用普通new我没有遇到过问题，而且问题是如果普通new都出现问题的时候，其他什么伎俩都没有什么意思了。问题还有就是什么时候nothrow new会返回NULL？这太罕见了，甚至如果我不偏执的话，也许一辈子也遇不到。通信包的应用可以导致Buffe

2006-03-30 18:22:00 740

原创 Exceptional C++ Style之22

第22条进行new的操作，也许会抛出异常之一：new的方方面面事情总是自以为了解很多，但实际上总有呼略的侧面，对new的理解也是如此。这一条对new做了很好的总结。通常的new，不抛出异常的new，定位的new。在全局范围内，可以对前两种new进行重载，但是在类范围内，可以对所有类型的new进行重载。关于名字隐藏，编译器对函数和对象的查找是从

2006-03-29 21:57:00 688

原创 Exceptional C++ Style之21

第21条内存中的容器之二：它到底有多大这篇写的是各种容器类的空间消耗，其实这并不是我所关注的问题。在目前的硬件条件下，通常对效率的要求往往超过了对空间的要求，我想选择一个数据结构的基本要求就是具有足够的特性，尤其是效率。需要特别注意的是一个地方就是数据的对齐，对于整个系统来说，进程内部的数据是不存在这样的问题（用指针移位来进行计算的除外）。通常来说，进程间的数

2006-03-29 21:18:00 657

原创 Exceptional C++ Style之20

第20条内存中的容器之一：内存管理的层次内存分配的层次通常是分这么几层，从内到外分别为，操作系统内核，operator new和malloc，标准容器和分配器，用户定义的容器和分配器。在代码编写的时候，需要注意各层做了什么，明白各层的策略和职责是非常必要的。

2006-03-29 21:11:00 572

原创 Exceptional C++ Style之19

第19条对派生类施加规则不要在析构函数中抛出异常，这是在《C++编程思想》中写的很明白的事情。不要使用异常规格，这在以前也看过，当然，目前没有足够的好处促使编写异常规格。避免编写虚的操作符重载，具体原因我也没有看见。需要对派生类加上限制的话，可以考虑在基类将其访问权限改为不可访问。尽量用编译期错误代替运行期错误。

2006-03-29 21:06:00 687

原创 Exceptional C++ Style之18

第18条虚拟虚拟也许是C++区别C的一个最显著特征之一。和模板不同，虚拟是需要带来运行期消耗的，具体原理参见《Inside C++ Object Model》。但是付出的代价表明，这个特性是绝对值得付出的。我们的设计通常是这样的，在一个基类中定义一些接口，这些接口都是虚拟的。期待派生类来进行实现，但是这个地方Sutter给出一个原则，在这个基础上更进一步。Su

2006-03-10 11:56:00 774

原创 Exceptional C++ Style之17

第17条封装封装的准则是将所有的数据成员放在私有区段。唯一的例外是C风格的struct，后者的意图并不在封装什么，因而其所有成员都可以是公用的。接口是最需要在第一时间就做对的事情，其他东西都可以在后期进行修正。如果一开始接口就错了，那么以后可能很难有机会修正。这个原则似乎不是那么明显，但如果在实际工程中，你就会发现这点有多么的重要。

2006-03-10 11:06:00 757

原创 Exceptional C++ Style之16

第16条（几乎）私有顺序，顺序。这里说的是重载三部曲——名字查找，重载决议，可访问性检查。这里写这个是因为重载决议在可访问性检查之前。所以出现可访问性问题，编译器不会因为隐式转换而通过重载避开，这里就是一个编译错误。Public和private是控制可访问性，而不是可见性，这点很重要。对于一个私有变量来说，似乎是无法保护的，C++中存在强大的指针，可以在知道内存布局的情况

2006-03-09 16:34:00 787

原创 Exceptional C++ Style之15

第15条访问权限的使用这似乎是对C++语言的一些讨论，但我想，在外部修改对象可以么？进程间。我想语音级别上是很严密的，剩下的就是系统级安全问题了。

2006-03-09 15:45:00 704

原创 Exceptional C++ Style之14

第14条顺序、顺序！继承是除了友元外，最强的联系，继承不是解决一切问题的办法，所以不要遇到什么事情就继承。还有关于顺序的问题，请参见《Inside C++ Object Model》，那里面远比这说的详细。

2006-03-09 15:17:00 671

原创 Exceptional C++ Style之13

第13条对异常规格的实际考虑令人遗憾的是，我没有在实际代码中看见一行异常规格。typedef不支持异常规范。对虚函数来数，派生类对异常规范比基类更加严格。异常规格常常是个善意的谎言，说这句话的时候，我其实有点疑惑，真的是善意？有时候可能叫做玩忽职守，或者什么其他的，但是这个地方真的是个问题。我完全认为这可能成为一个空头的承诺。事实上，不要为函数加上

2006-03-09 15:08:00 721

原创 Exceptional C++ Style之12

第12条异常安全性：值得吗资源获取即初始化，这里用到了智能指针的概念也就是说把资源管理的工作交给了构造函数和析构函数，这应该是个比较流行的办法，我遇到过因为分支产生的内存泄漏问题。如果可以的话，不要贸然返回。但是有什么好的办法？我在我的实践中考虑到效率的问题，需要及早返回。记得在Stack中讨论Top()和Pop()，这就是为什么函数要功能单一的真谛，如果需要

2006-03-09 14:31:00 717

原创 Exceptional C++ Style之11

第11条 try和catch 写在异常安全之前，是我看了一部分代码，看了很多的try/catch all的咚咚，I suppose是不是这些Catch都是异常安全的。事实上，我认为很多catch all仅仅为了保证程序还能运行，因为除了一行日志之外，我看不到什么别的咚咚。我不认为所有的地方都不需要做额外的动作。异常代码不是越多越多，事实上，异常代码影响C++的效率

2006-03-09 13:59:00 660

原创 Exceptional C++ Style之10

第10条导出限制之二：相互影响、可用性问题以及准则 export对C++来并不是如一个普通的关键字那么简单，它可能会导致一些规则的颠覆。而先前合法的一些使用会因为export的出现而产生二义性。更加复杂的是编译和链接不再像以往那么容易区别。Linker甚至会回头重新进行编译。这可在以前从来没有过。对于大多数人来，export没有意义，比如我，手头上没有支持exp

2006-03-09 10:47:00 627

原创 Inter SIU520 Log阅读

本文只针对SIU520日志阅读的技巧，不涉及7号信令，如果需要解析信令的话，请参考7号信令相关手册。 S7L:I0000 T 02c3600d M t8701 i017a f23 d4d s00 p0c1202809000 S7L —— SS7 Log I —— Instance，与标志一致。

2006-03-08 18:27:00 997 1

原创 Exceptional C++ Style之9

第9条导出限制之一：基础对export的期望值不能过高，说实话，他和lib库并不是一码事，虽然看上去似乎是一样的。怎么回事？通过export，在引入一个新的实现，也许是一个lib，并不是重新链接一下，就OK了。需要对所有改变的模板所到之处重新编译？Sutter的总结是export隐藏了源码依赖性，但并非消除。难道这里是模板的死结？

2006-03-07 15:45:00 695

原创 Exceptional C++ Style之8

第8条友元模板友元的声明有四种准则：一、如果给出显示的模板实参，将被认为是模板的具现。二、如果被一个名字空间或者类所限，在这个限定内确实可以匹配的函数或者类，那么就匹配这个东东。三、如果这之内有一个可以匹配的函数模板，那么可以认为是这个函数模板的隐式特化。四、否则就是一个普通函数。这里面给出的准则是关于友元的声明，可以写成如下两种：friend void boost::

2006-03-07 13:17:00 706

原创 Exceptional C++ Style之7

第7条为什么不特化函数模板有一个概念，我以前对偏特化不是特别清晰明了，模板分成类模板和函数模板，我原来是一致看待的。但是事实上，函数模板能不能偏特化，只能重载，每个看个偏特化的函数模板其实都是重载。函数模板并不参加重载决议，只有当主模板被选中，才有可能去选择某个特化版本。而且在选择主模板的时候，编译器并不关心特化模板。所以，如果你确实需要某个特化版本，那么写成

2006-03-07 10:52:00 658

原创 Exceptional C++ Style之6

第6条泛型性的风味之二：够“泛”了吗对泛型编程来说，如果需要限定模板输入参数是指针，那么它不算是一个泛型，只能说是一个特化版本。因为准则是，指针是迭代器，迭代器并非总是指针。当用一个模板来实现另一个模板，特别是它们存在一定的关系，那么这种关系有可能形成一些限制，导致某些泛型性的丧失。如果拥有标准模板库中，更好的实现函数，不妨用模板库中的函数，作为特化版本，可以

2006-03-03 11:22:00 608

原创 Call Ref及相关

在读NMS ISDN日志的时候，有着如下总结：1.Call Ref呼叫索引是在中继内复用的，而并非整块卡。循环复用。2.nai指的是中继号3.Group对T1有意义，T1一个D Channel管理多个中继，通过group来区分。4.channel number = 0x1F，这个代表通道号，从什么开始算起，这个需要看一看。检查起来分布是这样的。第0个通道在日志上是0x1,第29个是0

2006-03-03 10:19:00 786

原创思维定式

这次出去遇到一个问题，折腾了很久，结果发现是个非常容易解决的问题，问题本身只是个案，没有追述的意义。需要值得检讨的是，在解决问题的过程中，出现了思维定式。谁说呼叫一定要从seize call开始？事实上很多问题不要想得太复杂，想最简单最直接的办法去解决问题才是关键。通过绕很多弯子无助于问题的正确解决。真正的敌人其实是自己的思维习惯！

2006-03-02 20:58:00 728

原创 Exceptional C++ Style之5

第5条泛型性的风味之一：基础这部分其实新的内容不多，提出的主要概念是两个，第一个是编译期多态的概念。我对这部分的理解是，编译期多态和运行期多态，并不是说可以随意替换。它们只存在部分交集。编译期多态的好处在于消耗花在编译期，而运行期的额外消耗为零。如果条件允许应该适当用编译期多态来替代运行期多态。至于模板具现的二义性问题，在《C++编程思想》的第二卷中，已经

2006-03-02 13:38:00 665

原创 Exceptional C++ Style之4

第4条标准库成员函数关于mem_fun和mem_fun_ref的问题，先前在《Effective C++》中就写过了。这里不多些了。使用mem_fun，但不要用在标准库上。看了半天终于看懂了这段的意思，这个意思是在标准库中充斥着peekaboo参数，也就是说，你不一定能绑定正确的函数。所以，原则是，绑定你能控制的函数，对于标准库，这不是个人可以控制的，即使不同的实现也会有很

2006-03-01 16:53:00 707

原创 Exceptional C++ Style之3

第3条字符串格式化的“动物庄园”之二：标准的（极度优雅的）替代方案方案一、snprintf 这看上去是最简单的替代方案，给出的这个长度，可以有效限制buf的溢出。长度输入错误？出现这种事情自己检讨。比较来说，永远不要用sprintf，这好像有点残酷，不过snprintf其实是一回事。类似的情况还有很多，在这里就不赘述了。方案二、std::stringstream

2006-03-01 13:16:00 728

原创 Exceptional C++ Style之2

第2条字符串格式化的“动物庄园”之一：sprintf 对于Sutter来说，他肯定很不喜欢sprintf。我也不是特别的喜欢，但是不要忘了他的优点，简单，效率高，对我来说，效率非常非常重要，以至于它要成为一个习惯。我们来表述一下sprintf的原罪，类型安全性，这不单单是sprintf吧，所有格式化的c函数都存在这个问题，我们可以把它认为是c的原罪。那么，nex

2006-03-01 11:45:00 696

原创 Exceptional C++ Style之1

第1条 vector的使用访问vector的元素vector v;v[0];v.at[0];这有什么区别呢？at函数添加了exception::out_of_range; 当然这是要付出代价的，代价是性能的消耗。调整vector的大小我在读《c++编程思想》曾经调用过reserve接口，发现增长是指数性质的，一定大小比你要求的大小要大。当我们增加reserve的空

2006-03-01 10:53:00 721

李永亮的专栏