《Effectirve C++》笔记（条款21~40）_effect c++ 条款21 问题-优快云博客

本文链接：https://blog.youkuaiyun.com/supperlinux/article/details/104557755

本文探讨了C++编程中的关键原则与最佳实践，包括对象返回、成员变量封装、成员函数设计、异常安全、转型使用、编译依赖、public继承、虚函数选择等，旨在帮助程序员提高代码质量和维护性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

条款21：必须返回对象时，别妄想返回其reference

不要返回函数中new而存在于堆中对象的引用（不知道谁负责delete），不要返回函数局部变量的引用（栈中，这样函数结束实例已经被销毁）。不要反悔局部静态成员的引用，对于多线程不安全，对于连续调用行为也不可控，当真的需要返回一个对象时就返回对象而不是引用。

任何一个引用必然存在一个和他不同名的相同实例，不得不考虑另一个名字的行为。

条款22：将成员变量声明为private

protected并不比public更具封装性。数据成员的操作应具有一致性，public下无法保证调用者行为。

条款23：宁以non-member、non-friend替换member函数

可以把成员函数放到另一个class做为静态函数，以保证一个class就是对数据的封装，超出目的范围的提出来，保证封装性。

条款24：若所有参数皆需要类型转换，请为此采用non-member函数

能避免friend就避免，变成非成员函数以后若非必要不要加friend，朋友带来的麻烦往往多余价值。

条款25：考虑写出一个不抛出异常的swap函数

当swap对自定义类型效率不高时，应提供swap成员函数，并确保不发生异常。并提供一个非成员函数调用他。

对于建立的非成员函数，std命名空间中不能够扩充新的函数，重载也不行，对于函数的非成员swap要用全特化。template<> void swap(xx& a, xx& b){};

调用swap时神队std::swap使用using声明式，然后调用swap并不带任何命名空间资格修饰

条款26：尽可能延后变量定义式的出现时间

尽量在用的时候建立对象，不要提前建立。

对于循环，除非明确知道复制成本小于“构造+析构”成本，并且正在处理效率高度敏感的代码，否则不要把变量初始化放到循环外面。

确实从来没考虑过赋值成本与构造+析构的大小问题，单纯的只考虑了提出循环避免构造+析构。。。。从来都是写到外面的

条款27：尽量少做转型动作

提倡使用四个C++风格转型，不要用T(a)/(T)a这样的C方式转型。

const_cast常量性转换，唯一有此能力的C++转型符号

dynamic_cast主要用来进行安全向下转型，从父类引用或指针向派生类转换。派生类转父类用static_cast就行。这个需要消耗重大的运行成本

reinterpret_cast低级转型，行为和结果取决于编译器，不可移植。

static_cast强制转型，但无法进行const、non-const转换

static_cast也不能去掉volatile、__unaligned

reinterpret_cast以二进制形式对原有对象进行重新解释（可进行无关类型的转换），可以把指针转换为int等等，对一段区域的二进制内容进行赋值构成新的值并赋予新的类型解释，不会对二进制上的内容做任何修改，可用于：

从指针类型到一个足够大的整数类型
从整数类型或者枚举类型到指针类型
从一个指向函数的指针到另一个不同类型的指向函数的指针
从一个指向对象的指针到另一个不同类型的指向对象的指针
从一个指向类函数成员的指针到另一个指向不同类型的函数成员的指针
从一个指向类数据成员的指针到另一个指向不同类型的数据成员的指针

条款28：避免返回handles指向对象内部成分

对于const函数避免返回指针、引用、迭代器指向内部成员（包括const的指针引用迭代器），使一个const函数更像一个常量函数，并避免dangling handles虚吊号码牌。

条款29：为“异常安全”而努力是值得的

异常安全函数即使发生异常也不会泄露资源或允许任何数据结构破坏。这样的函数分为三种保证：

基本型：发生时，程序内任何事物仍然保持在有效状态下，不破坏对象和数据结构。但当前状态无法预料。

强烈类型：发生时，程序状态不变。

不抛异常型：int aa() throw();告知它宗科正常运行，不是永远不抛异常，而是如果发生将是致命错误。

绝大部分都在基本和强烈之间。一个系统有一个函数不具备异常安全性则整个系统都不具备。

一个函数的异常安全性不会超过所调用函数的最低异常安全性级别。

条款30：透彻了解inlining的里里外外

inline应用在小型、被频繁调用的函数上，对后续调试过程、二进制升级更好也可降低代码膨胀问题。

不要因为是函数模板就一定要声明为inline。

条款31：将文件间的编译依存关系降至最低

1想依赖于声明式，而不是定义式。头文件中应以完全且仅有声明式的形势存在，无论是否涉及模板。也就是私有成员用指针，前置声明对应class并在源文件中include。

2进一步的将私有成员过多情况下可以构建一个针对此class的实现类，并在声明类中的private只提供一个实现类的指针（用智能指针），将所有需要涉及到多个私有成员的实现操作转移到实现类。

3还可以用接口类。

对于2，类似于Qt库的实现，每个公开调用的类只有一个私有成员类名+private类的指针。

对于3，接口类要求无构造、虚析构、其他全部纯虚函数。无数据成员。谷歌C++编程规范（当然这部分说了不要前置声明任何std内容）：尽可能地避免使用前置声明。使用 #include 包含需要的头文件即可。

优点：

前置声明能够节省编译时间，多余的 #include 会迫使编译器展开更多的文件，处理更多的输入。
前置声明能够节省不必要的重新编译的时间。 #include 使代码因为头文件中无关的改动而被重新编译多次。

缺点：
前置声明隐藏了依赖关系，头文件改动时，用户的代码会跳过必要的重新编译过程。
前置声明可能会被库的后续更改所破坏。前置声明函数或模板有时会妨碍头文件开发者变动其 API. 例如扩大形参类型，加个自带默认参数的模板形参等等。
前置声明来自命名空间 std:: 的 symbol 时，其行为未定义。
很难判断什么时候该用前置声明，什么时候该用 #include 。极端情况下，用前置声明代替 includes 甚至都会暗暗地改变代码的含义：
// b.h:
struct B {};
struct D : B {}

// good_user.cc:
#include "b.h"
void f(B*);
void f(void*);
void test(D* x) { f(x); }  // calls f(B*)
如果 #include 被 B 和 D 的前置声明替代， test() 就会调用 f(void*) .

前置声明了不少来自头文件的 symbol 时，就会比单单一行的 include 冗长。
仅仅为了能前置声明而重构代码（比如用指针成员代替对象成员）会使代码变得更慢更复杂.
结论：

尽量避免前置声明那些定义在其他项目中的实体.
函数：总是使用 #include.
类模板：优先使用 #include.