zoukankan      html  css  js  c++  java
  • Effective C++ 笔记 —— Item 24: Declare non-member functions when type conversions should apply to all parameters.

    You might start your Rational class this way:

    class Rational 
    {
    public:
        Rational(int numerator = 0, // ctor is deliberately not explicit;
        int denominator = 1); // allows implicit int-to-Rational conversions
    
        int numerator() const; // accessors for numerator and denominator — see Item 22
        int denominator() const; 
    private:
        // ...
    };

    You know you’' like to support arithmetic operations like addition, multiplication, etc., but you're unsure whether you should implement them via member functions, non-member functions, or, possibly, nonmember functions that are friends.

    Let’s set that aside and investigate the idea of making operator* a member function of Rational:

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

    This design lets you multiply rationals with the greatest of ease:

    Rational oneEighth(1, 8);
    Rational oneHalf(1, 2);
    Rational result = oneHalf * oneEighth; // fine
    result = result * oneEighth; // fine

    When you try to do mixed-mode arithmetic, however, you find that it works only half the time:

    result = oneHalf * 2; // fine
    result = 2 * oneHalf; // error!

    The source of the problem becomes apparent when you rewrite the last two examples in their equivalent functional form:

    result = oneHalf.operator*(2); // fine
    result = 2.operator*(oneHalf ); // error

    The object oneHalf is an instance of a class that contains an operator*, so compilers call that function. However, the integer 2 has no associated class, hence no operator* member function. Compilers will also look for non-member operator*s (i.e., ones at namespace or global scope) that can be called like this:

    result = operator*(2, oneHalf ); // error!

    But in this example, there is no non-member operator* taking an int and a Rational, so the search fails.

    What’s going on is implicit type conversion for the first call.

    It turns out that parameters are eligible for implicit type conversion only if they are listed in the parameter list. The implicit parameter corresponding to the object on which the member function is invoked — the one this points to — is never eligible for implicit conversions. That’s why the first call compiles and the second one does not. The first case involves a parameter listed in the parameter list, but the second one doesn't.

    You’d still like to support mixed-mode arithmetic, however, and the way to do it is by now perhaps clear: make operator* a non-member function, thus allowing compilers to perform implicit type conversions on all arguments:

    class Rational 
    {
        // ... // contains no operator*
    };
    
    const Rational operator*(const Rational& lhs, // now a non-member
    
    const Rational& rhs) // function
    {
        return Rational(lhs.numerator() * rhs.numerator(),
        lhs.denominator() * rhs.denominator());
    }
    
    Rational oneFourth(1, 4);
    Rational result;
    result = oneFourth * 2; // fine
    result = 2 * oneFourth; // hooray, it works!

    This is certainly a happy ending to the tale, but there is a nagging worry. Should operator* be made a friend of the Rational class?

    In this case, the answer is no, because operator* can be implemented entirely in terms of Rational’s public interface. The code above shows one way to do it. That leads to an important observation: the opposite of a member function is a non-member function, not a friend function. Too many C++ programmers assume that if a function is related to a class and should not be a member (due, for example, to a need for type conversions on all arguments), it should be a friend. This example demonstrates that such reasoning is flawed. Whenever you can avoid friend functions, you should, because, much as in real life, friends are often more trouble than they’re worth. Sometimes friendship is warranted, of course, but the fact remains that just because a function shouldn’t be a member doesn’t automatically mean it should be a friend.

    Things to Remember:

    • If you need type conversions on all parameters to a function (including the one that would otherwise be pointed to by the this pointer), the function must be a non-member.
  • 相关阅读:
    Delphi中三种方法获取Windows任务栏的高度
    Qt中QFtp获取带有中文的文件名称出现乱码的解决方法(比较巧妙,toLatin1压缩掉了QString自动给每个英文字符加上的那些00字节)
    Qt在Linux环境下应用程序字体模糊的解决方法(先改成使用默认字体,然后使用qtconfig配置)
    关于Qt信号与槽机制的传递方向性研究(结论其实是错误的,但是可以看看分析过程)
    RCP:如何把Preferences中的项从一个类别移动到另一个类别 2013-08-23 18:59 by Binhua Liu,
    服务端套接字类CxServerSocket的使用
    ASP.NET MVC原理
    jQuery 2.0.3 源码分析core
    CodeBlocks的下载安装、配置、简单编程
    ASP.NET MVC学习笔记-----Filter2
  • 原文地址:https://www.cnblogs.com/zoneofmine/p/15239562.html
Copyright © 2011-2022 走看看