Guru of the Week 条款04: 类的构造技巧

GotW #04 Class Mechanics

著者：Herb Sutter     

翻译：kingofark

[声明]：本文内容取自www.gotw.ca网站上的Guru of the Week栏目，其著作权归原著者本人所有。译者kingofark在未经原著者本人同意的情况下翻译本文。本翻译内容仅供自学和参考用，请所有阅读过本文的人不要擅自转载、传播本翻译内容；下载本翻译内容的人请在阅读浏览后，立即删除其备份。译者kingofark对违反上述两条原则的人不负任何责任。特此声明。

Revision 1.0

Guru of the Week 条款04: 类的构造技巧

难度：7.5 / 10

（你在实现类的细节方面到底有多行？本条款不仅要讲述一些可怕的错误，还要更多的涉及专业的编码风格方面的内容。）

[问题]

    你正在考查另一个程序员编写的一个类（见下），这个类的编码风格很差劲，而且还有一些严重的错误。你能找到多少个，又怎么进行修改呢？ 

    class Complex {

    public:

        Complex( double real, double imaginary = 0 )

          : _real(real), _imaginary(imaginary) {};

         void operator+ ( Complex other ) {

            _real = _real + other._real;

            _imaginary = _imaginary + other._imaginary;

        }

         void operator<<( ostream os ) {

            os << "(" << _real << "," << _imaginary << ")";

        }

         Complex operator++() {

            ++_real;

            return *this;

        }

         Complex operator++( int ) {

            Complex temp = *this;

            ++_real;

            return temp;

        }

     private:

        double _real, _imaginary;

    };

  

[解答]

 [前言]：实际上，这个类所包含的错误比我们下面要讲述的还要多。但出这道难题的意图，与其说是要指出其设计得很差劲的接口，还不如说主要是为了体现类的构造技巧（比如，“典型的operator<<是如何实现的？”，“应该把operator+视为一个成员吗？”，等等）。不管怎么说吧，我将从非常有用的第0点开始讲起……

0． 既然标准库里面已经有一个Complex类，何苦自己再写一个呢？（更何况标准库里的这一个是集业内最优秀的高手们多年经验之结晶，绝对不会出现下面讲述的任何一个问题。所以嘛，你还是“不耻复用”吧！）

[学习指导]：请复用标准库的算法，而不要编写自己的算法版本。这样做更快、更容易、更安全！ 

 

*   class Complex {

    public:

        Complex( double real, double imaginary = 0 )

          : _real(real), _imaginary(imaginary) {}; 

1． 风格说明：这可以用作单一参数的构造函数（constructor），包含着一个隐式的转换操作。但注意，并不总是要故意这样做！ 

[学习指导]：千万要注意那些“悄悄进行的”转换操作。一个避免它的好办法就是尽可能显式（explicit）的使用构造函数（constructor）。 

 

*       void operator+ ( Complex other ) {

            _real = _real + other._real;

            _imaginary = _imaginary + other._imaginary;

        } 

2． 风格说明：出于效率的考虑，其参数应该是const&；而且，像“a = a + b”这样的语句应该被改写成“a += b”。 

[规则]：请传递const&，而不要传递拷贝。 

[学习指导]：对于算术操作，请使用“a op= b”的形式而不要使用“a = a op b”的形式（当然，在有些类里面——你应该从来都没有写过这种类的吧！？（汗）——op 和op= 之间并不是原本的等价关系。这种情况除外。）。 

3． 风格说明：operator+不应该被视为成员函数。如果它像上面的代码里面那样是一个成员函数，那你就只能写“a = b + 1”这样的语句而绝不能写成“a = 1 + b”。出于效率的考虑，你还可能想要提供operator+(Complex,int)和operator+(int,Complex)。 

[学习指导]：对于把一个运算符视为成员函数还是非成员函数，请遵循(Lakos96: 143-144; 591-595; Murray93: 47-49)中提到的规则，即 

l       一元运算符是成员函数

l       =，（），[]和->必须是成员函数

l       +=，-=，/=，*=（等等）是成员函数

l       所有其它的二元运算符是非成员函数 

4． 错误说明：operator+不应该改变这个对象的值，而应该返回一个包含相加结果的临时对象。注意，为了避免像“a + b = c”这样的用法，返回类型应该是const Complex（而不是Complex）。 

（实际上，这部分代码反而更接近于operator+=的实现，而不是operator+实现。） 

5． 风格说明：一般来说，如果你定义了op，那你也应该同时定义op=。就这里给出的代码而言，因为你定义了operator+，所以你也应该同时定义operator+=。如此一来，上面的函数无论如何都应该是对operator+=的实现（只不过返回值拧过来了，见下面的叙述）。 

*       void operator<<( ostream os ) {

            os << "(" << _real << "," << _imaginary << ")";

        } 

（作者记：对于一个正宗的operator<<而言，你还应该考虑到做一些额外的事情，比如检查流当前的格式化标志（format flag）以使其符合通常的用法。你可以查阅自己最好的STL方面的书籍，以获得更多详细的描述。在此推荐几本：Steve Teale的 《C++ IOStreams Handbook》，Glass 和 Schuchert的《The STL <Primer>》， 还有Plauger的《The (Draft) Standard C++ Library》。） 

6． 错误说明：operator<<不应该是一个成员函数（见上面说过的规则）；而且参数应该为(ostream&, const Complex&)。在这里还要注意，正如James Kanze所说，不让其成为一个友元将会更好！相应的，可以通过调用一个公有（public）的成员函数print来解决问题。 

7． 错误说明：函数的返回类型应该是ostream&；而且函数应该以“return os;”语句结束，从而允许链式表达式（即是说，你可以写“cout << a << b;”这样的语句）。 

[规则]：总是让operator<<和operator>>返回流引用（stream reference）。 

*       Complex operator++() {

            ++_real;

            return *this;

        } 

8． 风格说明：先增（preincrement）操作应该返回Complex&，让调用它的代码能够更直观的进行操作。

  

*       Complex operator++( int ) {

            Complex temp = *this;

            ++_real;

            return temp;

        } 

9． 风格说明：后增（postincrement）操作应该返回const Complex。这可以避免像a++++之类超出一个编码新手所能及的奇怪语句。 

10．风格说明：按照实现先增（preincrement）操作的模式去实现后增（postincrement）操作。 

[学习指导]：请按照实现先增（preincrement）操作的模式去实现后增（postincrement）操作。 

*      private:

          double _real, _imaginary;

      }; 

11． 风格说明：尽量避免使用以下划线开头的名称。是的，我老是习惯性的使用它们；不错，一些像《Design Patterns》（Gamma et al）那样极受欢迎的书也这样使用它们。但是一方面，C++标 准为了某些实现上的原因而保留了一部分以下划线开头的标识符；另一方面，无论对于你还是对于编译器的编写者来说，要记住相关的规则都是很困难的。所以，你 最好还是在自己的代码中避免使用以下划线开头的名称。（有鉴于我被禁止以下划线开头来表示我自己的成员变量之事实，我现在改用以下划线结尾的方式作为替代 方案！） 

好了。现在终于得到这个程序的正确代码版本，在这里我们忽略那些在上面没有提到过的有关设计和编码风格的问题： 

    class Complex {

    public:

        explicit Complex( double real, double imaginary = 0 )

          : real_(real), imaginary_(imaginary) {} 

        Complex& operator+=( const Complex& other ) {

            real_ += other.real_;

            imaginary_ += other.imaginary_;

            return *this;

        } 

        Complex& operator++() {

            ++real_;

            return *this;

        } 

        const Complex operator++( int ) {

            Complex temp = *this;

            ++(*this);

            return temp;

        } 

        ostream& print( ostream& os ) const {

            return os << "(" << real_

                      << "," << imaginary_ << ")";

        } 

    private:

        double real_, imaginary_;

        friend ostream& 

        operator<<( ostream& os, const Complex& c );

    }; 

    const Complex operator+( const Complex& lhs,

                             const Complex& rhs ) {

        Complex ret( lhs );

        ret += rhs;

        return ret;

    } 

    ostream& operator<<( ostream& os,

                         const Complex& c ) {

        return c.print(os);

    }