strchr函数用法_c++ strchr函数_strchr函数原型(11)

优点:变长数组具有浑然天成的语法.变长数组和alloca()也都很高效.

缺点:变长数组和alloca()不是标准C++的组成部分.更重要的是,它们根据数据大小动态分配堆栈内存,会引起难以发现的内存越界bugs:“在我的机器上运行的好好的,发布后却莫名其妙的挂掉了”.

结论:使用安全的内存分配器,如scoped_ptr/scoped_array.

友元：我们允许合理的使用友元类及友元函数.

通常友元应该定义在同一文件内,避免代码读者跑到其它文件查找使用该私有成员的类.经常用到友元的一个地方是将FooBuilder声明为Foo的友元,以便FooBuilder正确构造Foo的内部状态,而无需将该状态暴露出来.某些情况下,将一个单元测试类声明成待测类的友元会很方便.

友元扩大了(但没有打破)类的封装边界.某些情况下,相对于将类成员声明为public,使用友元是更好的选择,尤其是如果你只允许另一个类访问该类的私有成员时.当然,大多数类都只应该通过其提供的公有成员进行互操作.

异常：我们不使用C++异常.

优点:(1)、异常允许上层应用决定如何处理在底层嵌套函数中“不可能出现的”失败,不像错误码记录那么含糊又易出错;(2)、很多现代语言都使用异常.引入异常使得C++与Python,Java以及其它C++相近的语言更加兼容.(3)、许多第三方C++库使用异常,禁用异常将导致很难集成这些库.(4)、异常是处理构造函数失败的唯一方法.虽然可以通过工厂函数或Init()方法替代异常,但他们分别需要堆分配或新的“无效”状态；(5)、在测试框架中使用异常确实很方便.

缺点:(1)、在现有函数中添加throw语句时,你必须检查所有调用点.所有调用点得至少有基本的异常安全保护,否则永远捕获不到异常,只好“开心的”接受程序终止的结果.例如,如果f()调用了g(),g()又调用了h(),h抛出的异常被f捕获,g要当心了,很可能会因疏忽而未被妥善清理.(2)、更普遍的情况是,如果使用异常,光凭查看代码是很难评估程序的控制流:函数返回点可能在你意料之外.这会导致代码管理和调试困难.你可以通过规定何时何地如何使用异常来降低开销,但是让开发人员必须掌握并理解这些规定带来的代价更大.(3)、异常安全要求同时采用RAII和不同编程实践.要想轻松编写正确的异常安全代码,需要大量的支撑机制配合.另外,要避免代码读者去理解整个调用,异常安全代码必须把写持久化状态的逻辑部分隔离到“提交”阶段.它在带来好处的同时,还有成本(也许你不得不为了隔离“提交”而整出令人费解的代码).允许使用异常会驱使我们不断为此付出代价,即使我们觉得这很不划算.(4)、启用异常使生成的二进制文件体积变大,延长了编译时间(或许影响不大),还可能增加地址空间压力;(5)、异常的实用性可能会怂恿开发人员在不恰当的时候抛出异常,或者在不安全的地方从异常中恢复.例如,处理非法用户输入时就不应该抛出异常.如果我们要完全列出这些约束,这份风格指南会长出很多!

结论:(1)、从表面上看,使用异常利大于弊,尤其是在新项目中.但是对于现有代码,引入异常会牵连到所有相关代码.如果新项目允许异常向外扩散,在跟以前未使用异常的代码整合时也将是个麻烦.因为Google现有的大多数C++代码都没有异常处理,引入带有异常处理的新代码相当困难.(2)、鉴于Google现有代码不接受异常,在现有代码中使用异常比在新项目中使用的代价多少要大一些.迁移过程比较慢,也容易出错.我们不相信异常的使用有效替代方案,如错误代码,断言等会造成严重负担.(3)、我们并不是基于哲学或道德层面反对使用异常,而是在实践的基础上.我们希望在Google使用我们自己的开源项目,但项目中使用异常会为此带来不便,因此我们也建议不要在Google的开源项目中使用异常.如果我们需要把这些项目推倒重来显然不太现实.

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-35033-11.html