Google编程风格指南(二）

2. 作用域

2.1. 命名空间

Tip

鼓励在.cc文件内使用匿名命名空间或static声明. 使用具名的命名空间时, 其名称可基于项目名或相对路径. 禁止使用 using 指示（using-directive）。禁止使用内联命名空间（inline namespace）。

定义:

命名空间将全局作用域细分为独立的, 具名的作用域, 可有效防止全局作用域的命名冲突.

优点:

虽然类已经提供了（可嵌套的）命名轴线 (YuleFox 注: 将命名分割在不同类的作用域内), 命名空间在这基础上又封装了一层.

举例来说, 两个不同项目的全局作用域都有一个类Foo, 这样在编译或运行时造成冲突. 如果每个项目将代码置于不同命名空间中,project1::Foo和project2::Foo作为不同符号自然不会冲突.

内联命名空间会自动把内部的标识符放到外层作用域，比如：

namespace X {inline namespace Y {void foo();} // namespace Y} // namespace X

X::Y::foo()与X::foo()彼此可代替。内联命名空间主要用来保持跨版本的 ABI 兼容性。

缺点:

命名空间具有迷惑性, 因为它们使得区分两个相同命名所指代的定义更加困难。

内联命名空间很容易令人迷惑，毕竟其内部的成员不再受其声明所在命名空间的限制。内联命名空间只在大型版本控制里有用。

有时候不得不多次引用某个定义在许多嵌套命名空间里的实体，使用完整的命名空间会导致代码的冗长。

在头文件中使用匿名空间导致违背 C++ 的唯一定义原则 (One Definition Rule (ODR)).

结论:

根据下文将要提到的策略合理使用命名空间.

遵守命名空间命名中的规则。

像之前的几个例子中一样，在命名空间的最后注释出命名空间的名字。

用命名空间把文件包含,gflags的声明/定义, 以及类的前置声明以外的整个源文件封装起来, 以区别于其它命名空间:

// .h 文件namespace mynamespace {// 所有声明都置于命名空间中// 注意不要使用缩进class MyClass { public: ... void Foo();};} // namespace mynamespace// .cc 文件namespace mynamespace {// 函数定义都置于命名空间中void MyClass::Foo() { ...}} // namespace mynamespace

更复杂的.cc文件包含更多, 更复杂的细节, 比如 gflags 或 using 声明。

#include "a.h"DEFINE_FLAG(bool, someflag, false, "dummy flag");namespace a {...code for a... // 左对齐} // namespace a

不要在命名空间std内声明任何东西, 包括标准库的类前置声明. 在std命名空间声明实体是未定义的行为, 会导致如不可移植. 声明标准库下的实体, 需要包含对应的头文件.

不应该使用using 指示引入整个命名空间的标识符号。

// 禁止 —— 污染命名空间using namespace foo;

不要在头文件中使用命名空间别名除非显式标记内部命名空间使用。因为任何在头文件中引入的命名空间都会成为公开API的一部分。

// 在 .cc 中使用别名缩短常用的命名空间namespace baz = ::foo::bar::baz;// 在 .h 中使用别名缩短常用的命名空间namespace librarian {namespace impl { // 仅限内部使用namespace sidetable = ::pipeline_diagnostics::sidetable;} // namespace implinline void my_inline_function() { // 限制在一个函数中的命名空间别名 namespace baz = ::foo::bar::baz; ...}} // namespace librarian

禁止用内联命名空间

2.2. 匿名命名空间和静态变量

Tip

在.cc文件中定义一个不需要被外部引用的变量时，可以将它们放在匿名命名空间或声明为static。但是不要在.h文件中这么做。

定义:

所有置于匿名命名空间的声明都具有内部链接性，函数和变量可以经由声明为static拥有内部链接性，这意味着你在这个文件中声明的这些标识符都不能在另一个文件中被访问。即使两个文件声明了完全一样名字的标识符，它们所指向的实体实际上是完全不同的。

结论:

推荐、鼓励在.cc中对于不需要在其他地方引用的标识符使用内部链接性声明，但是不要在.h中使用。

匿名命名空间的声明和具名的格式相同，在最后注释上namespace:

namespace {...} // namespace

2.3. 非成员函数、静态成员函数和全局函数

Tip

使用静态成员函数或命名空间内的非成员函数, 尽量不要用裸的全局函数. 将一系列函数直接置于命名空间中，不要用类的静态方法模拟出命名空间的效果，类的静态方法应当和类的实例或静态数据紧密相关.

优点:

某些情况下, 非成员函数和静态成员函数是非常有用的, 将非成员函数放在命名空间内可避免污染全局作用域.

缺点:

将非成员函数和静态成员函数作为新类的成员或许更有意义, 当它们需要访问外部资源或具有重要的依赖关系时更是如此.

结论:

有时, 把函数的定义同类的实例脱钩是有益的, 甚至是必要的. 这样的函数可以被定义成静态成员, 或是非成员函数. 非成员函数不应依赖于外部变量, 应尽量置于某个命名空间内. 相比单纯为了封装若干不共享任何静态数据的静态成员函数而创建类, 不如使用2.1. 命名空间。举例而言，对于头文件myproject/foo_bar.h, 应当使用

namespace myproject {namespace foo_bar {void Function1();void Function2();} // namespace foo_bar} // namespace myproject

而非

namespace myproject {class FooBar { public: static void Function1(); static void Function2();};} // namespace myproject

定义在同一编译单元的函数, 被其他编译单元直接调用可能会引入不必要的耦合和链接时依赖; 静态成员函数对此尤其敏感. 可以考虑提取到新类中, 或者将函数置于独立库的命名空间内.

如果你必须定义非成员函数, 又只是在.cc文件中使用它, 可使用匿名2.1. 命名空间或static链接关键字 (如staticintFoo(){...}) 限定其作用域.

2.4. 局部变量

Tip

将函数变量尽可能置于最小作用域内, 并在变量声明时进行初始化.

C++ 允许在函数的任何位置声明变量. 我们提倡在尽可能小的作用域中声明变量, 离第一次使用越近越好. 这使得代码浏览者更容易定位变量声明的位置, 了解变量的类型和初始值. 特别是，应使用初始化的方式替代声明再赋值, 比如:

int i;i = f(); // 坏——初始化和声明分离int j = g(); // 好——初始化时声明vector v;v.push_back(1); // 用花括号初始化更好v.push_back(2);vector v = {1, 2}; // 好——v 一开始就初始化

属于if,while和for语句的变量应当在这些语句中正常地声明，这样子这些变量的作用域就被限制在这些语句中了，举例而言:

while (const char* p = strchr(str, '/')) str = p + 1;

Warning

有一个例外, 如果变量是一个对象, 每次进入作用域都要调用其构造函数, 每次退出作用域都要调用其析构函数. 这会导致效率降低.

// 低效的实现for (int i = 0; i < 1000000; ++i) { Foo f; // 构造函数和析构函数分别调用 1000000 次! f.DoSomething(i);}

在循环作用域外面声明这类变量要高效的多:

Foo f; // 构造函数和析构函数只调用 1 次for (int i = 0; i < 1000000; ++i) { f.DoSomething(i);}

2.5. 静态和全局变量

Tip

禁止定义静态储存周期非POD变量，禁止使用含有副作用的函数初始化POD全局变量，因为多编译单元中的静态变量执行时的构造和析构顺序是未明确的，这将导致代码的不可移植。

禁止使用类的静态储存周期变量：由于构造和析构函数调用顺序的不确定性，它们会导致难以发现的 bug 。不过constexpr变量除外，毕竟它们又不涉及动态初始化或析构。

静态生存周期的对象，即包括了全局变量，静态变量，静态类成员变量和函数静态变量，都必须是原生数据类型 (POD : Plain Old Data): 即 int, char 和 float, 以及 POD 类型的指针、数组和结构体。

静态变量的构造函数、析构函数和初始化的顺序在 C++ 中是只有部分明确的，甚至随着构建变化而变化，导致难以发现的 bug. 所以除了禁用类类型的全局变量，我们也不允许用函数返回值来初始化 POD 变量，除非该函数（比如getenv()或getpid()）不涉及任何全局变量。函数作用域里的静态变量除外，毕竟它的初始化顺序是有明确定义的，而且只会在指令执行到它的声明那里才会发生。

Note

Xris 译注:

同一个编译单元内是明确的，静态初始化优先于动态初始化，初始化顺序按照声明顺序进行，销毁则逆序。不同的编译单元之间初始化和销毁顺序属于未明确行为 (unspecified behaviour)。

同理，全局和静态变量在程序中断时会被析构，无论所谓中断是从main()返回还是对exit()的调用。析构顺序正好与构造函数调用的顺序相反。但既然构造顺序未定义，那么析构顺序当然也就不定了。比如，在程序结束时某静态变量已经被析构了，但代码还在跑——比如其它线程——并试图访问它且失败；再比如，一个静态 string 变量也许会在一个引用了前者的其它变量析构之前被析构掉。

改善以上析构问题的办法之一是用quick_exit()来代替exit()并中断程序。它们的不同之处是前者不会执行任何析构，也不会执行atexit()所绑定的任何 handlers. 如果您想在执行quick_exit()来中断时执行某 handler（比如刷新 log），您可以把它绑定到_at_quick_exit(). 如果您想在exit()和quick_exit()都用上该 handler, 都绑定上去。

综上所述，我们只允许 POD 类型的静态变量，即完全禁用vector(使用 C 数组替代) 和string(使用constchar[])。

如果您确实需要一个class类型的静态或全局变量，可以考虑在main()函数或pthread_once()内初始化一个指针且永不回收。注意只能用 raw 指针，别用智能指针，毕竟后者的析构函数涉及到上文指出的不定顺序问题。

Note

Yang.Y 译注:

上文提及的静态变量泛指静态生存周期的对象, 包括: 全局变量, 静态变量, 静态类成员变量, 以及函数静态变量.

译者 (YuleFox) 笔记

cc中的匿名命名空间可避免命名冲突, 限定作用域, 避免直接使用using关键字污染命名空间;

嵌套类符合局部使用原则, 只是不能在其他头文件中前置声明, 尽量不要public;

尽量不用全局函数和全局变量, 考虑作用域和命名空间限制, 尽量单独形成编译单元;

多线程中的全局变量 (含静态成员变量) 不要使用class类型 (含 STL 容器), 避免不明确行为导致的 bug.

作用域的使用, 除了考虑名称污染, 可读性之外, 主要是为降低耦合, 提高编译/执行效率.

译者（acgtyrant）笔记

注意「using 指示（using-directive）」和「using 声明（using-declaration）」的区别。

匿名命名空间说白了就是文件作用域，就像 C static 声明的作用域一样，后者已经被 C++ 标准提倡弃用。

局部变量在声明的同时进行显式值初始化，比起隐式初始化再赋值的两步过程要高效，同时也贯彻了计算机体系结构重要的概念「局部性（locality）」。

注意别在循环犯大量构造和析构的低级错误。

3. 类

类是 C++ 中代码的基本单元. 显然, 它们被广泛使用. 本节列举了在写一个类时的主要注意事项.

3.1. 构造函数的职责

总述

不要在构造函数中调用虚函数, 也不要在无法报出错误时进行可能失败的初始化.

定义

在构造函数中可以进行各种初始化操作.

优点

无需考虑类是否被初始化.

经过构造函数完全初始化后的对象可以为const类型, 也能更方便地被标准容器或算法使用.

缺点

如果在构造函数内调用了自身的虚函数, 这类调用是不会重定向到子类的虚函数实现. 即使当前没有子类化实现, 将来仍是隐患.

在没有使程序崩溃 (因为并不是一个始终合适的方法) 或者使用异常 (因为已经被禁用了) 等方法的条件下, 构造函数很难上报错误

如果执行失败, 会得到一个初始化失败的对象, 这个对象有可能进入不正常的状态, 必须使用boolisValid()或类似这样的机制才能检查出来, 然而这是一个十分容易被疏忽的方法.

构造函数的地址是无法被取得的, 因此, 举例来说, 由构造函数完成的工作是无法以简单的方式交给其他线程的.

结论

构造函数不允许调用虚函数. 如果代码允许, 直接终止程序是一个合适的处理错误的方式. 否则, 考虑用Init()方法或工厂函数.

构造函数不得调用虚函数, 或尝试报告一个非致命错误. 如果对象需要进行有意义的 (non-trivial) 初始化, 考虑使用明确的 Init() 方法或使用工厂模式. AvoidInit()methods on objects with no other states that affect which public methods may be called (此类形式的半构造对象有时无法正确工作).

3.2. 隐式类型转换

总述

不要定义隐式类型转换. 对于转换运算符和单参数构造函数, 请使用explicit关键字.

定义

隐式类型转换允许一个某种类型 (称作源类型) 的对象被用于需要另一种类型 (称作目的类型) 的位置, 例如, 将一个int类型的参数传递给需要double类型的函数.

除了语言所定义的隐式类型转换, 用户还可以通过在类定义中添加合适的成员定义自己需要的转换. 在源类型中定义隐式类型转换, 可以通过目的类型名的类型转换运算符实现 (例如operatorbool()). 在目的类型中定义隐式类型转换, 则通过以源类型作为其唯一参数 (或唯一无默认值的参数) 的构造函数实现.

explicit关键字可以用于构造函数或 (在 C++11 引入) 类型转换运算符, 以保证只有当目的类型在调用点被显式写明时才能进行类型转换, 例如使用cast. 这不仅作用于隐式类型转换, 还能作用于 C++11 的列表初始化语法:

class Foo { explicit Foo(int x, double y); ...};void Func(Foo f);

此时下面的代码是不允许的:

Func({42, 3.14}); // Error

这一代码从技术上说并非隐式类型转换, 但是语言标准认为这是explicit应当限制的行为.

优点

有时目的类型名是一目了然的, 通过避免显式地写出类型名, 隐式类型转换可以让一个类型的可用性和表达性更强.

隐式类型转换可以简单地取代函数重载.

在初始化对象时, 列表初始化语法是一种简洁明了的写法.

缺点

隐式类型转换会隐藏类型不匹配的错误. 有时, 目的类型并不符合用户的期望, 甚至用户根本没有意识到发生了类型转换.

隐式类型转换会让代码难以阅读, 尤其是在有函数重载的时候, 因为这时很难判断到底是哪个函数被调用.

单参数构造函数有可能会被无意地用作隐式类型转换.

如果单参数构造函数没有加上explicit关键字, 读者无法判断这一函数究竟是要作为隐式类型转换, 还是作者忘了加上explicit标记.

并没有明确的方法用来判断哪个类应该提供类型转换, 这会使得代码变得含糊不清.

如果目的类型是隐式指定的, 那么列表初始化会出现和隐式类型转换一样的问题, 尤其是在列表中只有一个元素的时候.

结论

在类型定义中, 类型转换运算符和单参数构造函数都应当用explicit进行标记. 一个例外是, 拷贝和移动构造函数不应当被标记为explicit, 因为它们并不执行类型转换. 对于设计目的就是用于对其他类型进行透明包装的类来说, 隐式类型转换有时是必要且合适的. 这时应当联系项目组长并说明特殊情况.

不能以一个参数进行调用的构造函数不应当加上explicit. 接受一个std::initializer_list作为参数的构造函数也应当省略explicit, 以便支持拷贝初始化 (例如MyTypem={1,2};).

3.3. 可拷贝类型和可移动类型

总述

如果你的类型需要, 就让它们支持拷贝 / 移动. 否则, 就把隐式产生的拷贝和移动函数禁用.

定义

可拷贝类型允许对象在初始化时得到来自相同类型的另一对象的值, 或在赋值时被赋予相同类型的另一对象的值, 同时不改变源对象的值. 对于用户定义的类型, 拷贝操作一般通过拷贝构造函数与拷贝赋值操作符定义.string类型就是一个可拷贝类型的例子.

可移动类型允许对象在初始化时得到来自相同类型的临时对象的值, 或在赋值时被赋予相同类型的临时对象的值 (因此所有可拷贝对象也是可移动的).std::unique_ptr就是一个可移动但不可复制的对象的例子. 对于用户定义的类型, 移动操作一般是通过移动构造函数和移动赋值操作符实现的.

拷贝 / 移动构造函数在某些情况下会被编译器隐式调用. 例如, 通过传值的方式传递对象.

优点

可移动及可拷贝类型的对象可以通过传值的方式进行传递或者返回, 这使得 API 更简单, 更安全也更通用. 与传指针和引用不同, 这样的传递不会造成所有权, 生命周期, 可变性等方面的混乱, 也就没必要在协议中予以明确. 这同时也防止了客户端与实现在非作用域内的交互, 使得它们更容易被理解与维护. 这样的对象可以和需要传值操作的通用 API 一起使用, 例如大多数容器.

拷贝 / 移动构造函数与赋值操作一般来说要比它们的各种替代方案, 比如Clone(),CopyFrom()orSwap(), 更容易定义, 因为它们能通过编译器产生, 无论是隐式的还是通过=default. 这种方式很简洁, 也保证所有数据成员都会被复制. 拷贝与移动构造函数一般也更高效, 因为它们不需要堆的分配或者是单独的初始化和赋值步骤, 同时, 对于类似省略不必要的拷贝这样的优化它们也更加合适.

移动操作允许隐式且高效地将源数据转移出右值对象. 这有时能让代码风格更加清晰.

缺点

许多类型都不需要拷贝, 为它们提供拷贝操作会让人迷惑, 也显得荒谬而不合理. 单件类型 (Registerer), 与特定的作用域相关的类型 (Cleanup), 与其他对象实体紧耦合的类型 (Mutex) 从逻辑上来说都不应该提供拷贝操作. 为基类提供拷贝 / 赋值操作是有害的, 因为在使用它们时会造成对象切割. 默认的或者随意的拷贝操作实现可能是不正确的, 这往往导致令人困惑并且难以诊断出的错误.

拷贝构造函数是隐式调用的, 也就是说, 这些调用很容易被忽略. 这会让人迷惑, 尤其是对那些所用的语言约定或强制要求传引用的程序员来说更是如此. 同时, 这从一定程度上说会鼓励过度拷贝, 从而导致性能上的问题.

结论

如果需要就让你的类型可拷贝 / 可移动. 作为一个经验法则, 如果对于你的用户来说这个拷贝操作不是一眼就能看出来的, 那就不要把类型设置为可拷贝. 如果让类型可拷贝, 一定要同时给出拷贝构造函数和赋值操作的定义, 反之亦然. 如果让类型可拷贝, 同时移动操作的效率高于拷贝操作, 那么就把移动的两个操作 (移动构造函数和赋值操作) 也给出定义. 如果类型不可拷贝, 但是移动操作的正确性对用户显然可见, 那么把这个类型设置为只可移动并定义移动的两个操作.

如果定义了拷贝/移动操作, 则要保证这些操作的默认实现是正确的. 记得时刻检查默认操作的正确性, 并且在文档中说明类是可拷贝的且/或可移动的.

class Foo { public: Foo(Foo&& other) : field_(other.field) {} // 差, 只定义了移动构造函数, 而没有定义对应的赋值运算符. private: Field field_;};

由于存在对象切割的风险, 不要为任何有可能有派生类的对象提供赋值操作或者拷贝 / 移动构造函数 (当然也不要继承有这样的成员函数的类). 如果你的基类需要可复制属性, 请提供一个publicvirtualClone()和一个protected的拷贝构造函数以供派生类实现.

如果你的类不需要拷贝 / 移动操作, 请显式地通过在public域中使用=delete或其他手段禁用之.

// MyClass is neither copyable nor movable.MyClass(const MyClass&) = delete;MyClass& operator=(const MyClass&) = delete;

3.4. 结构体 VS. 类

总述

仅当只有数据成员时使用struct, 其它一概使用class.

说明

在 C++ 中struct和class关键字几乎含义一样. 我们为这两个关键字添加我们自己的语义理解, 以便为定义的数据类型选择合适的关键字.

struct用来定义包含数据的被动式对象, 也可以包含相关的常量, 但除了存取数据成员之外, 没有别的函数功能. 并且存取功能是通过直接访问位域, 而非函数调用. 除了构造函数, 析构函数,Initialize(),Reset(),Validate()等类似的用于设定数据成员的函数外, 不能提供其它功能的函数.

如果需要更多的函数功能,class更适合. 如果拿不准, 就用class.

为了和 STL 保持一致, 对于仿函数等特性可以不用class而是使用struct.

注意: 类和结构体的成员变量使用不同的命名规则.

3.5. 继承

总述

使用组合 (YuleFox 注: 这一点也是 GoF 在 <> 里反复强调的) 常常比使用继承更合理. 如果使用继承的话, 定义为public继承.

定义

当子类继承基类时, 子类包含了父基类所有数据及操作的定义. C++ 实践中, 继承主要用于两种场合: 实现继承, 子类继承父类的实现代码;接口继承, 子类仅继承父类的方法名称.

优点

实现继承通过原封不动的复用基类代码减少了代码量. 由于继承是在编译时声明, 程序员和编译器都可以理解相应操作并发现错误. 从编程角度而言, 接口继承是用来强制类输出特定的 API. 在类没有实现 API 中某个必须的方法时, 编译器同样会发现并报告错误.

缺点

对于实现继承, 由于子类的实现代码散布在父类和子类间之间, 要理解其实现变得更加困难. 子类不能重写父类的非虚函数, 当然也就不能修改其实现. 基类也可能定义了一些数据成员, 因此还必须区分基类的实际布局.

结论

所有继承必须是public的. 如果你想使用私有继承, 你应该替换成把基类的实例作为成员对象的方式.

不要过度使用实现继承. 组合常常更合适一些. 尽量做到只在 “是一个” (“is-a”, YuleFox 注: 其他 “has-a” 情况下请使用组合) 的情况下使用继承: 如果Bar的确 “是一种”Foo,Bar才能继承Foo.

必要的话, 析构函数声明为virtual. 如果你的类有虚函数, 则析构函数也应该为虚函数.

对于可能被子类访问的成员函数, 不要过度使用protected关键字. 注意, 数据成员都必须是私有的.

对于重载的虚函数或虚析构函数, 使用override, 或 (较不常用的)final关键字显式地进行标记. 较早 (早于 C++11) 的代码可能会使用virtual关键字作为不得已的选项. 因此, 在声明重载时, 请使用override,final或virtual的其中之一进行标记. 标记为override或final的析构函数如果不是对基类虚函数的重载的话, 编译会报错, 这有助于捕获常见的错误. 这些标记起到了文档的作用, 因为如果省略这些关键字, 代码阅读者不得不检查所有父类, 以判断该函数是否是虚函数.

3.6. 多重继承

总述

真正需要用到多重实现继承的情况少之又少. 只在以下情况我们才允许多重继承: 最多只有一个基类是非抽象类; 其它基类都是以Interface为后缀的纯接口类.

定义

多重继承允许子类拥有多个基类. 要将作为纯接口的基类和具有实现的基类区别开来.

优点

相比单继承 (见继承), 多重实现继承可以复用更多的代码.

缺点

真正需要用到多重实现继承的情况少之又少. 有时多重实现继承看上去是不错的解决方案, 但这时你通常也可以找到一个更明确, 更清晰的不同解决方案.

结论

只有当所有父类除第一个外都是纯接口类时, 才允许使用多重继承. 为确保它们是纯接口, 这些类必须以Interface为后缀.

注意

关于该规则, Windows 下有个特例.

3.7. 接口

总述

接口是指满足特定条件的类, 这些类以Interface为后缀 (不强制).

定义

当一个类满足以下要求时, 称之为纯接口:

只有纯虚函数 (“=0”) 和静态函数 (除了下文提到的析构函数).

没有非静态数据成员.

没有定义任何构造函数. 如果有, 也不能带有参数, 并且必须为protected.

如果它是一个子类, 也只能从满足上述条件并以Interface为后缀的类继承.

接口类不能被直接实例化, 因为它声明了纯虚函数. 为确保接口类的所有实现可被正确销毁, 必须为之声明虚析构函数 (作为上述第 1 条规则的特例, 析构函数不能是纯虚函数). 具体细节可参考 Stroustrup 的The C++ Programming Language, 3rd edition第 12.4 节.

优点

以Interface为后缀可以提醒其他人不要为该接口类增加函数实现或非静态数据成员. 这一点对于多重继承尤其重要. 另外, 对于 Java 程序员来说, 接口的概念已是深入人心.

缺点

Interface后缀增加了类名长度, 为阅读和理解带来不便. 同时, 接口属性作为实现细节不应暴露给用户.

结论

只有在满足上述条件时, 类才以Interface结尾, 但反过来, 满足上述需要的类未必一定以Interface结尾.

3.8. 运算符重载

总述

除少数特定环境外, 不要重载运算符. 也不要创建用户定义字面量.

定义

C++ 允许用户通过使用operator关键字对内建运算符进行重载定义, 只要其中一个参数是用户定义的类型.operator关键字还允许用户使用operator""定义新的字面运算符, 并且定义类型转换函数, 例如operatorbool().

优点

重载运算符可以让代码更简洁易懂, 也使得用户定义的类型和内建类型拥有相似的行为. 重载运算符对于某些运算来说是符合符合语言习惯的名称 (例如==,<, =, <<), 遵循这些语言约定可以让用户定义的类型更易读, 也能更好地和需要这些重载运算符的函数库进行交互操作.

对于创建用户定义的类型的对象来说, 用户定义字面量是一种非常简洁的标记.

缺点

要提供正确, 一致, 不出现异常行为的操作符运算需要花费不少精力, 而且如果达不到这些要求的话, 会导致令人迷惑的 Bug.

过度使用运算符会带来难以理解的代码, 尤其是在重载的操作符的语义与通常的约定不符合时.

函数重载有多少弊端, 运算符重载就至少有多少.

运算符重载会混淆视听, 让你误以为一些耗时的操作和操作内建类型一样轻巧.

对重载运算符的调用点的查找需要的可就不仅仅是像 grep 那样的程序了, 这时需要能够理解 C++ 语法的搜索工具.

如果重载运算符的参数写错, 此时得到的可能是一个完全不同的重载而非编译错误. 例如:foo< bar 执行的是一个行为, 而 &foo < &bar 执行的就是完全不同的另一个行为了.

重载某些运算符本身就是有害的. 例如, 重载一元运算符&会导致同样的代码有完全不同的含义, 这取决于重载的声明对某段代码而言是否是可见的. 重载诸如&&,||和,会导致运算顺序和内建运算的顺序不一致.

运算符从通常定义在类的外部, 所以对于同一运算, 可能出现不同的文件引入了不同的定义的风险. 如果两种定义都链接到同一二进制文件, 就会导致未定义的行为, 有可能表现为难以发现的运行时错误.

用户定义字面量所创建的语义形式对于某些有经验的 C++ 程序员来说都是很陌生的.

结论

只有在意义明显, 不会出现奇怪的行为并且与对应的内建运算符的行为一致时才定义重载运算符. 例如,|要作为位或或逻辑或来使用, 而不是作为 shell 中的管道.

只有对用户自己定义的类型重载运算符. 更准确地说, 将它们和它们所操作的类型定义在同一个头文件中,.cc中和命名空间中. 这样做无论类型在哪里都能够使用定义的运算符, 并且最大程度上避免了多重定义的风险. 如果可能的话, 请避免将运算符定义为模板, 因为此时它们必须对任何模板参数都能够作用. 如果你定义了一个运算符, 请将其相关且有意义的运算符都进行定义, 并且保证这些定义的语义是一致的. 例如, 如果你重载了<, 那么请将所有的比较运算符都进行重载, 并且保证对于同一组参数, < 和 >不会同时返回true.

建议不要将不进行修改的二元运算符定义为成员函数. 如果一个二元运算符被定义为类成员, 这时隐式转换会作用域右侧的参数却不会作用于左侧. 这时会出现a< b 能够通过编译而 b < a 不能的情况, 这是很让人迷惑的.

不要为了避免重载操作符而走极端. 比如说, 应当定义==,=, 和<< 而不是 Equals(), CopyFrom()和 PrintTo(). 反过来说, 不要只是为了满足函数库需要而去定义运算符重载. 比如说, 如果你的类型没有自然顺序, 而你要将它们存入 std::set 中, 最好还是定义一个自定义的比较运算符而不是重载 <.

不要重载&&,||,,或一元运算符&. 不要重载operator"", 也就是说, 不要引入用户定义字面量.

类型转换运算符在隐式类型转换一节有提及.=运算符在可拷贝类型和可移动类型一节有提及. 运算符<< 在 流 一节有提及. 同时请参见 函数重载 一节, 其中提到的的规则对运算符重载同样适用.

3.9. 存取控制

总述

将所有数据成员声明为private, 除非是staticconst类型成员 (遵循常量命名规则). 处于技术上的原因, 在使用Google Test时我们允许测试固件类中的数据成员为protected.

3.10. 声明顺序

总述

将相似的声明放在一起, 将public部分放在最前.

说明

类定义一般应以public:开始, 后跟protected:, 最后是private:. 省略空部分.

在各个部分中, 建议将类似的声明放在一起, 并且建议以如下的顺序: 类型 (包括typedef,using和嵌套的结构体与类), 常量, 工厂函数, 构造函数, 赋值运算符, 析构函数, 其它函数, 数据成员.

不要将大段的函数定义内联在类定义中. 通常，只有那些普通的, 或性能关键且短小的函数可以内联在类定义中. 参见内联函数一节.

译者 (YuleFox) 笔记

不在构造函数中做太多逻辑相关的初始化;

编译器提供的默认构造函数不会对变量进行初始化, 如果定义了其他构造函数, 编译器不再提供, 需要编码者自行提供默认构造函数;

为避免隐式转换, 需将单参数构造函数声明为explicit;

为避免拷贝构造函数, 赋值操作的滥用和编译器自动生成, 可将其声明为private且无需实现;

仅在作为数据集合时使用struct;

组合 > 实现继承 > 接口继承 > 私有继承, 子类重载的虚函数也要声明virtual关键字, 虽然编译器允许不这样做;

避免使用多重继承, 使用时, 除一个基类含有实现外, 其他基类均为纯接口;

接口类类名以Interface为后缀, 除提供带实现的虚析构函数, 静态成员函数外, 其他均为纯虚函数, 不定义非静态数据成员, 不提供构造函数, 提供的话, 声明为protected;

为降低复杂性, 尽量不重载操作符, 模板, 标准类中使用时提供文档说明;

存取函数一般内联在头文件中;

声明次序:public->protected->private;

函数体尽量短小, 紧凑, 功能单一;