《Effective C++》学习笔记

构造/析构/赋值运算：

条款5:了解C++默默编写并调用哪些函数。

编译器可以暗自为class创建default构造函数，copy构造函数，copy assignment操作符，以及析构函数。

 

条款6:若不想使用编译器自动生成的函数，就该明确拒绝。

为驳回编译器自动（暗自）提供的机能，可将相应的成员函数声明为private并且不予实现。

如果不慎调用，会得到一个连接错误。

也可以写一个基类：

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

再写你要写的类，去继承它。class不再声明copy构造函数或copy assignment操作符

 

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

1.带多态性质的base class应该声明一个virtual析构函数。如果class带有任何virtual函数，它就应该拥有一个virtual析构函数。

2.classes的设计目的如果不是作为base class使用，或不是为了具备多态性，就不该声明virtual函数。

无端的将所有classes的析构函数声明为virtual，就像从未声明他们为virtual一样，都是错误的。因为会增加vptr，所以增加对象大小。

如果试图继承一个标准容器或任何其他“带有non-virtual析构函数”的class，也是错误。

說一下啊：书上43页说C++没有提供“禁止派生”的机制。但是在C11貌似提供了final关键字，这个关键字有禁用继承和禁用重写功能。

 

条款8:别让异常逃离析构函数

1.析构函数绝对不要吐出异常。如果一个被析构函数调用的函数可能抛出异常，析构函数应该捕捉任何异常，然后吞下它们（不传播）或结束程序。

2.如果客户需要对某个操作函数运行期间跑出的异常做出反应，那么class应该提供一个普通函数（而非在析构函数中）执行该操作。

C++虽并不禁止析构函数吐出异常，但是还是不要在析构函数抛出异常。

 

条款9:绝不再构造和析构过程中调用virtual函数

在构造和析构期间不要调用virtual函数，因为这类调用从不下降至derived class（比起当前执行构造函数和析构函数那层）。

在base class构造期间，virtual函数不是virtual函数。由于base class构造函数的执行更早于derived class构造函数，当base class构造函数执行时derived class的成员变量尚未初始化。

面对未被初始化的部分，最安全的做法是视它们不存在。对象在derived class构造函数开始执行前不会成为一个derived class对象。

析构也是。一旦derived class析构函数开始执行，对象内的derived class成员变量便呈现未定义值，所以C++视他们不存在。

 

条款10:令operator=返回一个reference to *this

令赋值操作符返回一个reference to *this

为了实现“连锁赋值”，赋值操作符必须返回一个reference指向操作符的左侧实参。

 

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

1.确保当对象自我赋值时operator=有良好行为。其中技术包括比较“来源对象”和“目标对象”的地址、精心周到的语句顺序、以及copy-and-swap

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

 

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

1.Copying函数应该确保复制“对象内的所有成员变量”以及“所有base class 成分”

2.不要尝试以某个copying函数实现另一个copying函数。应该将共同机能放进第三个函数，并由两个copying共同调用

copy构造函数和copy assignment操作符，称为copying函数。

任何时候只要“为derived class 写copying函数”，必须小心地复制其base class 成分。那些成分往往是private，所以无法直接访问，应该让derived class的copying函数调用相应的base class函数。

 

3资源管理：

条款13:以对象管理资源

1.为防止资源泄露，请使用RAII对象，它们在构造函数中获得资源，并在析构函数中释放资源

2.两个常被使用的RAII classes分别是tr1::shared_ptr和auto_ptr。前者通常是较佳选择，因为其copy行为比较直观，若选择auto_ptr，复制动作会使它（被复制物）指向null。

把资源放进对象内，我们便可依赖C++的“析构函数自动调用机制”确保资源被释放。

以对象管理资源的观念称为“资源取得时机便是初始化时机”RAII，因为我们几乎总是在获得一笔资源后于同一语句内以它初始化某个管理对象。

auto_ptr的一个性质，若通过copy构造函数或copy assignment操作符复制它们，它们会变成null，而复制所得的指针将取得资源的唯一拥有权。所以容器容不得auto_ptr

 

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

1.复制RAII对象必须一并复制它所管理的资源，所以资源的copying行为决定RAII对象的copying行为

2.普遍而常见的RAII class copying行为是：抑制copying、施行引用计数法。不过其他行为也都可能被实现。

这里说的其他行为是：1.复制底部资源，进行的是深拷贝。2.还有就是“转移底部资源的拥有权”，auto_ptr

这里讲了一个问题，也是我之前面试遇到的一个问题，即怎样确保不会忘记unlock。

建立一个class管理锁：

class Lock{
public:
    explicit Lock(Mutex* pm):mutexPtr(pm)
    {
        lock(mutexPtr);  //获得资源
    ]
    ~Lock()
    {
        unlock(mutexPtr);//释放资源
    }
private:
    Mutex* mutexPtr;    
};

当发生复制。使用引用计数法，shared_ptr允许指定“删除器”，一个函数或函数对象，当引用计数为0时被调用

class Lock{
public:
    explicit Lock(Mutex* pm):mutexPtr(pm,unlock)//以某个Mutex初始化shared_ptr
    {                                           //并以unlock函数为删除器 
        lock(mutexPtr.get());  //获得资源
    ]
    //这里就没必要声明析构函数
   // ~Lock()
   // {
   //     unlock(mutexPtr);//释放资源
   // }
private:
    std::tr1::shared_ptr mutexPtr;//使用shared_ptr替换raw pointer    
};

 

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

1.APIs往往要求访问原始资源，所以每一个RAII class应该提供一个“取得其所管理之资源”的方法

2.对原始资源的访问可能经由显式转换或隐式转换。一般而言显示转换比较安全，但隐式转换对客户比较方便

 

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

如果你在new表达式中使用[]，必须在相应的delete表达式中也使用[]。如果如果你在new表达式中不使用[]，一定不要在相应的delete表达式中使用[]。

使用new时，有两件事发生，第一，内存被分配出来（通过operator new），第二，针对此内存会有一个（或更多）构造函数被调用。使用delete时，也差不多。

 

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

以独立语句将newed对象存储于（置入）智能指针内。如果不这样做，一旦异常被抛出，有可能导致难以察觉的资源泄露。

例如：

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

如果像下面这样调用，不会通过编译，因为shared_ptr的构造函数是个explicit构造函数，无法进行隐式转换

processWidget(new Widget,priority());

再修改：

processWidget(std::tr1::shared_ptr(new Widget),priority());

可以通过编译，但是可能造成资源泄露。

因为在调用函数之前，编译器做了三件事情：1.调用priority 2.执行new Widget 3.调用tr1::shared_ptr构造函数.

由于完成的次序问题不确定，所以可能发送资源泄露。所以需要将他们分离

std::tr1::shared_ptr pw(new Widget);
processWidget(pw,priority());

 

4.设计与声明

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

1.好的接口很容易被正确使用，不容易被误用。你应该在你的所有接口中努力达成这些性质

2.“促进正确使用”的办法包括接口的一致性，以及与内置类型的行为兼容

3.“阻止误用”的办法包括建立新类型、限制类型上的操作，束缚对象值，以及消除客户的资源管理责任

4.tr1::shared_ptr支持定制型删除器（custom deleter）。这可防范DLL问题，可被用来自动解除互斥锁等等。

 

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

 

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

1.尽量以pass-by-reference-to-const替换pass-by-value。前者通常比较高效，并可避免切割问题

2.以上规则并不适用于内置类型，以及STL的迭代器和函数对象。对他们而言，pass-by-value往往比较恰当

传引用高效的多，没有任何构造函数或析构函数被调用，因为没有任何新的对象被创建。

以pass-by-reference方式传递参数可避免对象切割问题。当一个derived class对象以by value方式传递并被视为一个base class对象，base class的copy构造函数会被调用，而“造成此对象的行为像个derived class对象”的那些特化性质全被切割掉了，仅仅留下一个base class对象。

引用往往以指针实现出来，因此传引用通常意味着传递的是指针。

 

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

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

任何时候看到一个reference声明式，我们应该问自己，它的另一个名称是什么。

 

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

1.切记将成员变量声明为private。这可赋予客户访问数据的一致性、可细微划分访问控制、允诺约束条件获得保证，并提供class作者以充分的实现弹性。

2.protected并不比public更具封装性。

声明为私有的理由：语法一致性，因为public的每样东西都是函数；使用函数可以让你对成员变量的处理由更精确的控制；最后重要的是【封装】。如果你对客户隐藏成员变量，你可以确保class的约束条件总是会获得维护，因为只有成员函数可以影响他们。

 

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

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

 

class WebBrowser{
public:
    ...
    void clearCache();
    void clearHistory();
    void removeCookies();
    ...
};

假如在class里面有如下的成员函数，这个函数调用上面三个函数。

void clearEverything();

另一种写法，用一个non-member函数调用：

void clearBrowser(WebBrowser& wb)
{
    wb.clearCache();
    wb.clearHistory();
    wb.removeCookies();
}

成员函数clearEverything提供的封装性比non-member函数clearBrowser低。

封装使我们能够改变事物而只影响有限客户。

对象内的数据，越多函数能访问他，数据的封装性越低。

 

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

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

例：一个有理数的类，需要进行乘法运算

class Rational{
public:
    ...
    const Rational operator* (const Rational& rhs) const;
};

Rational oneEighth(1,8);
Rational oneHalf(1,2);
Rational result = oneHalf * oneEighth; 正确
result = result * oneEighth;    正确

混合运算：

result = oneHalf * 2;    正确
result = 2 * oneHalf;    错误

原因是，这里发生了隐式类型转换。

第一句相当于：

const Rational temp(2);
result = oneHalf * temp;

如果Rational的构造函数是explicit，那么它也会错。

 

一个正确一个错误的原因是，只有当参数被列于参数列内，这个参数才是隐式类型转换的合格参与者。this对象不是隐式转换的合格参与者。

解决上面的问题：

让 operator* 成为non-member函数

class Rational{
    ... 这里就不包括operator*
};

const Rational operator*(const Rational& lhs, const Rational& rhs)
{
    ...
}

这样就不会出现上面的错误。

还有，member函数的反面是non-member函数，而不是friend函数。不能够只因函数不该成为member，就自动让他成为friend。

 

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

1.当std::swap对你的类型效率不高时，提供一个swap成员函数，并确定这个函数不抛出异常

2.如果你提供一个member swap，也该提供一个non-member swap用来调用前者。对于classes（而非templates），也请特化std::swap

3.调用swap时应针对std::swap使用using声明式，然后调用swap并且不带任何“命名空间资格修饰”。

4.为“用户定义类型”进行std templates全特化是好的，但千万不要尝试在std内加入某些对std而言全新的东西。

 

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

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

 

过早定义变量encrypted：

std::string encryptPassword(const std::string& password)
{
    using namespace std;
    string encrypted;
    if(...)
    {
        throw.....;
    }
    .......将一个加密后的密码置入变量encrypted内

    return encrypted;
}

最佳做法：

std::string encryptPassword(const std::string& password)
{
    ...和前面一样
    
    std::string encrypted(password); 通过copy构造函数定义并初始化
    encrypt(encrypted);

    return encrypted;
}

 

如果有循环，变量只在循环内使用：

方法A 定义在循环体外
Widget w;
for(int i =0;i < n;++i)
{
    w = 取决于i的某个值；
    ...
}


方法B 定于与循环体内

for(int i =0;i < n;++i)
{
    Widget w(取决于i的某个值)；
    ...
}

对于A： 1个构造函数 + 1个析构函数 + n个赋值操作

对于B： n个构造函数 + n 个析构函数

如果class的一个赋值成本低于一组构造+析构，尤其是n很大时，A更好。否则B更好。

此外A造成名称w的作用域比B大。

 

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

1.如果可以，尽量避免转型，特别是在注重效率的代码中避免dynamic_casts。如果有个设计需要转型动作，试着发展无需转型的替代设计。

2.如果转型是必要的，试着将它隐藏于某个函数背后。客户随后可以调用该函数，而不需将转型放进他们自己的代码内。

3.宁可使用C++ - style（新式）转型，不要使用旧式转型。前者很容易辨识出来，而且也比较有着分门别类的职掌。

 

旧式转型：

C风格：
(T)expression

函数风格转型
T(expression)

 

C++新式转型

const_cast(expression)
dynamic_cast(expression)
reinterpret_cast(expression)
static_cast(expression)

const_cast通常被用来将对象的常量性转除。它也是唯一有此能力的C++ - style转型操作符

dynamic_cast主要用来执行“安全向下转型”，也就是用来决定某对象是否归属继承体系中的某个类型。他是唯一无法由旧式语法执行的动作，也是唯一可能耗费重大运行成本的转型动作

reinterpret_cast意图执行低级转型，实际动作（及结果）可能取决于编译器，这也就表示它不可移植。

static_cast用来强迫隐式转换

 

未完。。。