Effective C++读书笔记（持续更新）

*流泪坨码头*

已于 2024-07-11 12:54:13 修改

阅读量1.2k

点赞数 37

文章标签： c++ visual studio

于 2024-06-03 14:23:01 首次发布

本文链接：https://blog.csdn.net/XT3121000506/article/details/139413634

版权

一、让自己习惯C++

条款01：视C++为一个语言联邦

C++高效编程守则视状况而变化，取决于你使用C++的哪一部分

条款02：尽量以const，enum，inline替换#define

对于单纯常量，最好以const对象或enum替换#define
对于形似函数的宏，最好改用inline函数替换#define

条款03：尽可能使用const

const出现在星号左边，表示被指物是常量；const出现在星号右侧，表示指针是常量

std::vector<int> vec;
...;
const std::vector<int>::iterator iter   // iter的作用像个T* const 
    = vec.begin();
std::vector<int>::const_iterator cIter // iter的作用像个const T*
    = vec.begin();

两个成员函数如果只是常量行不同，可以重载；意味着const成员函数和非const成员函数可以重名
将某些东西声明为const可以帮助编译器侦测出错误用法。const可被施加于任何作用域内的对象、函数参数、函数返回类型、成员函数本体。
编译器强制实施bitwise constness，但你编写程序时应该使用”概念上的常量性“
当const和non-const成员函数有着实质等价的实现时，令non-const版本调用const版本可避免代码重复。

条款04：确定对象被使用前已先被初始化

为内置型对象进行手工初始化，因为C++不保证初始化他们
构造函数最好使用成员初值列，而不要在构造函数本体内使用赋值操作。初值列列出的成员变量，其排列次序应该和他们在class中的声明次序相同。
为免除”跨编译单元之初始化次序“问题，请以local static对象替换non-local static对象。

二、构造、析构、赋值运算

条款5：了解C++默默编写并调用那些函数

编译器可以自己为class创建defualt构造函数、copy构造函数、copy assignment操作符、以及析构函数
如果在含有引用&或者const修饰的成员变量的类需要支持赋值操作(copy assignment)，则需要自己定义赋值操作，不可以依赖编译器提供的。
在基类的copy assigment操作符声明为private，编译器拒绝为该继承类提供copy assignment。

条款6：若不想编译器自动生成的函数，应该明确拒绝

使用如下手段，可以编译器不会为类提供拷贝函数和=重载等号运算符

class Uncopyable {
protected:
    Uncopyable() {};
    ~Uncopyable() {};
private:
    Uncopyable(const Uncopyable&);
    Uncopyable& operator = (const Uncopyable&);
};

// 为阻止HomeForSale对象被拷贝，需要继承Uncopybale
class HomeForSale :private Uncopyable {

};

条款7：为多态基类声明virtual析构函数

带有多态性质的base class应该声明一个virtual 析构函数。如果class带有任何的virtual函数，它就应该拥有一个virtual析构函数
class的设计目的如果不是作为base class使用，或不是为了具备多态性，就不应该声明virtual析构函数

条款08：别让异常逃离析构函数

析构函数绝对不要吐出异常。如果一个被析构函数调用的函数可能抛出异常，析构函数应该捕捉任何异常，然后吞下（不传播）或结束程序。
如果客户需要对某个操作函数运行期间抛出的异常作出反应，那么class应该提供一个普通函数（而非在析构函数中）执行该操作。

条款09：绝不在构造和析构过程中调用virtual函数

在构造函数和析构期间不要调用virtual函数，那是因为这类调用从不下降至derived class

条款10：令operator= 返回引用 to *this

令赋值(assignment)操作符返回一个指向*this的引用(+=，-=，*=都适用)

条款11：在operator= 中处理“自我赋值”

确保当对象自我赋值时operator= 有良好行为。

其中技术包括：

比较“来源对象”和“目标对象”的地址(利用if语句判别if(来源this == 目标this))

/* 类的定义 */
class Bitmap{...};
class Widget{
    ...
private:
    Bitmap* pb;
};

Widget& widget::operator= (const Widget& rhs)
{
    if(this == &rhs)    return *this;
    delete pb;
    pb = new Bitmap(*rhs.pb);
    return *this;
}

精心周到的语句顺序（拷贝一份来源对象，new(来源对象)、delete（目标对象））

Widget& widget::operator= (const Widget& rhs)
{
    Bitmap* pOrig = pb;         // 记住原先的pb
    pb = new Bitmap(*rhs.pb);   // 令pb指向rhs.pb的一个副本
    delete pOrig;               // 删除原先的pb
    return *this;
}

以及copy-and-swap"

Widget& widget::operator= (const Widget& rhs)
{
    Wiget temp(rhs);    // 为rhs数据制作一个副本
    swap(temp);         // 和副本交换数据
}

确定任何函数如果操作一个以上的对象，而其中多个对象时同一对象时，其行为依然正确

条款12：复制对象时勿忘其每一个成分

Copying函数应该确保复制“对象内的所有成员变量”及“所有base class成分”。
不要尝试以某个copying函数实现另一个copying函数。如果拷贝构造函数和赋值运算符有相同操作，则应将相同操作封装成一个方法，将其限定在private中。

三、资源管理

条款13：以对象管理资源

为防止资源泄露，使用RAII对象
两个常被使用的RAII classes分别是tr1::shared_ptr 和 auto_ptr。前者通常是最佳选择，因为其copy行为比较直观，支持拷贝构造和assignment 操作符，而auto_ptr不可支持两种操作，复制动作会使它(被复制物)指向null

class Investment{};

Investment* createInvestment()
{
    return new(Investment);
}

auto_ptr<Investment> pInv(createInvestment());
std::tr1::shared_ptr<Investment> test(createInvestment());

int main()
{

    auto_ptr<Investment> pInv1(createInvestment());
    auto_ptr<Investment> pInv2(pInv1);

    tr1::shared_ptr<Investment> test1(createInvestment());
    tr1::shared_ptr<Investment> test2(test1);
    test1 = test2;
    return 0;
}

结果：

条款14：在资源管理类中小心copying行为

复制RAII对象必须一并复制它所管理的资源，所以资源的copying行为决定RAII对象的copying行为。
普遍而常见的RAII class copying行为是：抑制copying、施行引用计数法。

条款15：在资源管理类中提供对原始资源的访问

tr1::shared_ptr 和 auto_ptr都提供一个get成员函数，用来执行显示转换，可以返回智能指针内部的原始指针(的复件)。
APIs往往要求访问原始资源，所以每一个RAII class应该提供一个"取得其所管理之资源的办法"。
对原始资源的访问可能经由显示转换或隐式转换，一般而言显示转换更安全。

条款16：成对使用new和delete时要采取相同形式

在new中使用[],在delete也要使用[]。

条款17：以独立语句将newed对象置入智能指针

int priority();
void processWidget(std::tr1::shared_ptr<Widget> pw, int priority);

/* 现在考虑调用 */
processWidget(std::tr1::shared_ptr<Widget>(new Widget), priority());
/* 请不要这样做，在调用这个语句之前，编译器要做以下三件事
调用priority()
执行 new Widget
调用std::tr1::shared_ptr<Widget>的构造函数
由于无法确认这三个动作的次序，可能会导致一个结果：
1、执行 new Widget
2、调用priority()
3、调用std::tr1::shared_ptr<Widget>的构造函数 */

/* 如果调用priority()发生异常，那么new Widget的这块空间会引起资源泄露 */

// 故将代码改成如下
调用std::tr1::shared_ptr<Widget> pw(new Widget);
processWidget(pw,priorty()); // 不会引发泄露

以独立语句将newed对象存储(置入)智能指针中。如果不这样做，一旦异常引发，有可能会导致资源泄露。

四、设计与声明

条款18：让接口容易被正确使用，不易被误用

好的接口很容易被正确使用，不容易被误用。
“促进正确使用”的办法包括接口的一致性、以及与内置类型的行为兼容
“阻止误用”的办法包括建立新类型、限制类型上的操作，束缚对象值，以及消除客户的资源管理责任
tr1::shared_ptr支持定制删除器。这可防止DLL问题。

条款19：设计class犹如设计type

Class的设计就是type的设计。在定义一个新的type之前，请确定已经考虑郭本条款所覆盖的全部讨论主题

条款20：宁以pass-by-reference-to-const 替换 pass-by-value

尽量以pass-by-reference-to-const 替换 pass-by-value
以上规则并不适用于内置类型，以及STL的迭代器和函数对象。对他们而言，pass-by-vlaue 往往比较适当

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

绝不要返回pointer或reference指向一个 local stack对象，或返回referece指向一个heap-allocated对象，或返回pointer或reference指向一个local static对象而有可能同时需要多个这样的对象。

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

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

宁可拿non-member non-friend函数替换member函数。这样做可以增加封装性、包裹弹性和机能扩充性。

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

如果你需要为某个函数的所有参数(包括被this指针指向的那个隐喻参数)进行类型转换，那么这个函数必须是个non-member。

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

没看懂，可能暂时不太需要看懂

五、实现

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

尽可能延后变量式的出现。这样做可增加程序的清晰度并改善程序效率。

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

如果可以、尽量避免转型，特别是在注重效率的代码中避免dynamic_casts。
如果转型是必要的，试着将它隐藏于某个函数背后，客户随时可以调用该函数，而不需要将转型放进他们自己的代码内
宁可使用C++-style转型，也不要使用旧式转型。前者很容易辨识出来。

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

避免返回handles(包括引用、指针、迭代器)指向对象内部。遵守这个条约可以增加封装性、帮助const成员函数的行为像个const，并将发生“虚吊号码牌”的可能性将低到最低

条款29：为“异常安全”而努力是值得的（跳过先）

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

将大多数inlining限制在小型、被频繁调用的函数身上。这可使日后的调试过程和二进制升级更容易，也可使潜在的代码膨胀问题最小化，使程序的速度提升机会最大化
不要只因为function templates出现在头文件，就将他们声明为inline

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

六、继承与面向对象设计

条款32：确定你的public继承塑膜出is-a关系

"public"继承意味着is-a。适用于base classes身上的每一件事情一定也适用于derived classes身上，因为每一个derived class对象也都是一个base class对象。

条款33：避免遮掩继承而来的名称

derived classes内的名称会遮掩base classes内的名称。在public继承下从来没有人会希望如此
为了让被遮掩的名称在见天日，可用using 声明式或转交函数。

条款34：区分接口继承和实现继承

继承接口和实现接口不同。在public继承之下，derived class总是继承base class的接口
pure virtual函数只具体指定接口继承
impure virtual具体指定接口继承及缺省实现继承
non-virtual函数具体指定接口继承以及强制性实现继承

条款35：考虑virtual函数以外的其他选择

本条款的根本忠告是，当你为解决问题而寻找某个设计方法时，不妨考虑virtual函数的替代方案。下面快速重点复习我们验证过的几个替代方案：

使用non-virtual interface（NVI）手法，那是Template Method设计模式的一种特殊形式。他以public non-virtual成员函数包裹较低访问性（private或proteceted）的virtual函数
将virtual函数替换为"函数指针成员变量"，这是Strategy设计模式的一种分解表现形式.
以 tr1::function成员变量替换virtual函数，因而允许使用任何可调用物（callble enity）搭配一个兼容于需求的签名式。这是*Strategy设计模式的某种行驶
将继承体系内的virtual函数替换为另一个继承体系内的virtual函数。这是Stagery设计模式的传统实现手法。

请记住：

virtual函数的替代方案包括NVI手法及Strategy设计模式的多种形式。NVI手法自身是一个特殊形式的Template Method设计模式
将机能从成员函数移到class外部函数，带来的一个缺点是，是非成员函数无法访问class内的non-public成员。
tr1::function对象的行为就像一般函数指针。这样的对象可接纳“与给定之目标签名式兼容”的所有可调物。