C++的营养

swap手法

    swap手法不应当是C++独有的技术，很多语言都可以实现，并且从中得到好处。只是C++存在的一些缺陷迫使大牛们发掘，并开始重视这种有用的手法。这 个原本被用来解决C++的资源安全和异常保证问题的技术在使用中逐步体现出越来越多的应用，有助于我们编写更加简洁、优雅和高效的代码。
    接下来，我们先来和swap打个招呼。然后看看在C#里如何玩出swap。最后展示swap手法的几种应用，从中我们将看到它是如何的可爱。
    假设，我要做一个类，实现统计并保存一个字符串中字母的出现次数，以及总的字母和数字的个数。
    在类CountStr中，定义了swap成员函数。swap接受一个CountStr&类型的参数。在函数中，我们可以看到一组函数调用，每一个 对应一个数据成员，其任务是将相对应的数据成员的内容相互交换。此处，我使用了两种调用，一种是使用std::swap()标准函数，另一种是通过 swap成员函数执行这个交换。一般情况下，std::swap()通过一个临时变量实现对象的内容交换。但对于string、map等非平凡的对象，这 种交换会引发至少三次深拷贝，其复杂度将是O(3n)的，性能极差。因此，标准库为这些类定义了swap成员函数，通过成员函数可以实现O(1)的交换操 作。同时将std::swap()针对这些拥有swap()成员函数的标准容器特化，使其可以直接使用swap()成员函数，而避免性能损失。但是，对于 那些拥有swap()成员，但没有被特化的用户定义，或第三方的类，则不应使用std::swap()，而改用swap()成员函数。所以，一般情况下， 为了避免混淆，对于拥有swap()成员函数的类，调用swap()，否则调用标准std::swap()函数。
    顺便提一下，在未来的C++0x中，由于引入了concept机制，可以允许一个函数模板自动识别出所有“具有swap()成员”的类型，并使用相应的特化版本。这样便只需使用std::swap()，而不必考虑是什么样的类型了。
    言归正传。这里，swap()成员函数有两个要求，其一是复杂度为O(1)，其二是具备无抛掷的异常保证。前者对于性能而言至关重要，否则swap操作将 会由于性能问题而无法在实际项目中使用。对于后者，是确保强异常保证（commit or rollback语义）的基石。要达到这两个要求，有几个关键要点：首先，对于类型为内置类型或小型POD（8～16字节以内）的成员数据，可以直接使用 std::swap()；其次，对于非平凡的类型（拥有资源引用，复制构造和赋值操作会引发深拷贝），并且拥有符合上述要求的swap()成员函数的，直 接使用swap()成员函数；最后，其余的类型，则保有其指针，或智能指针，以确保满足上述两个要求。
    听上去有些复杂，但在实际开发中做到并不难。首先，尽量使用标准库容器，因为标准库容器都拥有满足两个条件的swap()成员。其次，在编写的每一个类中 实现满足两个条件的swap()成员。最后，对于那些不具备swap()成员函数的第三方类型，则使用指针，最好是智能指针。（也就是Sutter所谓的 PImpl手法）。只要坚持这些方针，必能收到很好的效果。
    下面，就来看一下这个swap()的第一个妙用。假设，这个类需要复制。通常可以通过operator=操作符，或者copy（或其他有明确的复制含义 的）成员函数实现，这两者实际上是等价的，只是形式不同而已。这里选择operator=，因为它比较C++:)。
    最直白的实现方式是这样：
    很简单，但是不安全，或者说没有满足异常保证。
    先解释一下异常保证。异常保证有三个级别：基本保证、强异常保证和无抛掷保证。基本保证是指异常抛出时，程序的各个部分应当处于有效状态，不能有资源泄 漏。这个级别可以轻而易举地利用RAII确保，这在前一篇已经展示过了。强异常保证则更加严格，要求异常抛出后，程序非但要满足基本保证，其各个部分的数 据应保持原状。也就是要满足“Commit or Rollback”语义，熟悉数据库的人，可以联想一下Transaction的行为。而无抛掷保证要求函数在任何情况下都不会抛出异常。无抛掷保证不是 说用一个catch(...)或throw()把异常统统吞掉。而是说在无抛掷保证的函数中的任何操作，都不会抛出异常。能满足无抛掷保证的操作还是很多 的，比如内置POD类型（int、指针等等）的复制，swap手法便以此为基础。（多说一句，用catch(...)吞掉异常来确保无抛掷并非绝对不行， 在特定情况下，还是可以偶尔一用。不过这等烂事也只能在西构函数中进行，而且也只有在迫不得已的情况下用那么一下）。
    如果这四个赋值操作 中，任意一个抛出异常，便会退出这个函数（操作符）。此时，至少有一个成员数据没有正确修改，而其他的则全部或部分地发生改变。于是，一部分成员数据是新 的，另一部分是旧的，甚至还有一些是不完全的。这在软件中往往会引发很多令人苦恼的bug。无论如何，此时应当运用强异常保证，使得数据要么是新的值，要 么没有改变。那么如何获得强异常保证？在swap()的帮助下，惊人的简单：
    我想世上没有比这等代码更加漂亮的了吧！不仅仅具有简洁动人的外表，而且充满了丰富的内涵。这就叫优雅。不过，优雅之下还需要一些解释。在这两个版本中， 都是先用复制构造创建一个临时对象，这个临时对象同传入的参数对象拥有相同的值。然后用swap()成员函数将this对象的内容与临时对象交换。于是， this对象拥有了临时对象的值，也就是与传入的实参对象具有相同的值（复制）。当退出函数的时候，临时对象销毁，自然而然地释放了this对象原先的资 源（前提是CountStr类实现了RAII）。
    那么抛出异常的情况又是怎样的呢？
    先来看看operator=里执行了哪些步骤，并考察这些步骤的异常抛掷的情况。如果将代码改写成另一个等价的形式，就很容易理解了：
    在构造临时对象的时候，可能会抛出异常，因为此时执行了数据的复制和构造。请注意，这时候this对象的内容没有改变。如果此时抛出异常，数据发生改变的 只有t_，this对象并未受到影响。而随着栈清理，t_也将被析构，在RAII的作用下，t_所占用的资源也会依次释放。而下一步，swap()成员的 调用，则是无抛掷保证的，不会抛出异常，this的内容可以得到充分地、原子地交换，不会发生数据值修改一半的情况。
    在C#中，实现swap非常容易，甚至比C++更容易。因为在C#中，大部分对象都在堆上，代码中定义的所谓对象实际上是引用。对于引用的赋值操作是无抛掷的，因此在C#中可以采用同C++几乎一样的代码实现swap：
    这里utility.swap()是一个泛型函数，作用是交换两个参数：
    如果类有关键性的资源需要释放，那么可以实现IDisposable接口，然后在copy()中使用using：
    如此，对象原有的数据和资源被交换到临时对象t_中之后，在退出using作用域的时候，会立即得到释放。这是RAII的一个应用，详细内容参见本系列的前一篇《C++的营养——RAII》。
    swap的基本作用是维持强异常保证语义。但是，作为一种基础性的技术，它还可以拥有更多的用途。下面介绍几种主要的应用，为了节省篇幅，案例直接使用C#，不再给出C++的代码。
    在我们的开发过程中，有时需要是一些对象复位，即回复对象的初始状态。一般情况下，我们会在类中增加一个reset()之类的成员，在这个函数中释放资源，恢复各成员数据的初值。但是，在拥有swap的情况下，这种操作变得非常容易：
    reset()用X的默认构造函数创建了一个临时对象，将其内容与this交换，this的内容便成为了初始值。重要的是，这个成员函数也是强异常保证的。如果需要通过一些参数复位，那么同样可以做到：
    有时甚至可以不需要reset这个成员，而直接在代码中使用swap复位一个对象：
    如果X有资源需要释放，那么只需实现IDispose，然后使用using：
    上面这些应用都有一个共同点，即重新初始化一个对象，使其恢复到一个初始状态。下面的应用，则反其道而行之，将一个对象切换到另一个状态。
    有时，我们会做一些类，在构造函数中执行一些复杂的操作，比如解析一个文本文件，然后向外公布解析后的结果。之后，我们需要在这个对象上load另一个文 件，那么通常都写一个load成员函数，先释放掉原先占用的资源，然后再加载新的文件。如果有了swap，那么这个load函数同样极其简单：
    还有一种情况，有一些类，通过一些数据创建，创建之后在绝大多数的情况下都是只读的，但偶尔会需要改变其内部数据。为了代码的可靠性，我们可以把类写成只读的。但是如何修改其内部的数据呢？也可以通过swap：
    这样便可避免对Z的实例的随意修改。但是，这种修改方式会造成性能损失，特别是数据成员存在非O(1)复制的情况下（如有字符串、数组等），只有在修改偶尔发生的情况下才能使用。
    有些类，构造函数需要一些数据初始化对象，并且会创建的过程中会验证其有效性，和执行一些计算。也就是构造函数存在一定的数据逻辑。如果需要修改对象的某 些值，会牵涉到相应的复杂数据逻辑。通常都是把这些逻辑独立在private成员函数中，由构造函数和数据修改操作共享。这样的做法往往不能带来强异常保 证，在构造函数里的数据验证往往会抛出异常。因此，如果使用swap，便可以消除这类问题，并且使代码简化：
    当然，也可以在类外直接进行这样的数据设置：
    这种用法可以用于某些只保存对构造函数参数的计算结果，而不需要保存这些参数的类（m_a，m_b，m_c都不需要了），只是使用上过于琐碎。
    所有这些与对象状态设置有关的swap用法，都集中表现了一个特性，即使得我们可以将对象的初始化代码集中在构造函数中，数据和资源清理的代码集中在 Dispose()中。这种做法可以大大提高代码的可维护性。如果一个软件项目中，每个类都实现swap和复制构造函数（除非该类不允许复制），并尽可能 集中数据逻辑代码，那么会使得代码质量有答复的提高。
    在上一篇《C++的营养——RAII》中，我提到守卫一个结构复杂的类：在代码中修改一个对象，然后再回复原来的状态。如果单纯手工地保存对象数据，通常 很困难（有时甚至是不可能的），而且也难以维持异常安全性（强异常保证）。但是如果使用了swap，那么将会易如反掌：
    当然，也可以直接使用t_执行操作，这就不需要执行swap。在一般情况下两者是等价的。但是，在某些特殊情况下，比如类持有特殊资源，或者obj是并发 中的共享对象的时候，两种方法有可能不等价。swap方案使用上更全面些。总的来说相差不多，放在这里仅供参考。
    作为更进一步的发展，可以构造一个ISwapable泛型接口：
    对于需要实现swap手法的类，实现这个接口：
    这将会带来一个好处，通过泛型算法实现某些特定的操作：
    这样便无须为每一个类编写reset成员函数，只需这一个泛型算法即可：
    swap手法可能在存在其他诸多应用，在编码的时候可以不断地发掘。只需要抓住一个原则：swap可以无抛掷，简洁地修改一个对象的值。swap所带来的 一个问题主要是性能方面。swap通常伴随着临时对象的构造，多数情况下，这种构造不会引发更多的性能损失，但在某些数据修改的应用中，会比直接的数据修 改损失更多的性能。如何取舍，需要根据具体情况分析和权衡。总的来说，swap手法所带来的好处是显而易见的，特别是强异常保证，往往是至关重要的。而诸 如简化代码等的作用，则无需多言，一用便知。
    或许swap手法非常基础，非常细小，而且很多人不用swap也过来了。但是，聚沙成塔，每一处细小的优化，积累起来则是巨大的进步。还是刘皇叔说得好：“勿以善小而不为，勿以恶小而为之”。