重载运算符中没有隐式转换

发布于 2024-10-02 20:24:58 字数 487 浏览 3 评论 0原文

d1 + 4 有效,但 4 + d1 无效,即使 4 可以隐式转换为 GMan。为什么它们不相等?

struct GMan
{
    int a, b;

    GMan() : a(), b() {}
    GMan(int _a) : a(_a), b() {}
    GMan(int _a, int _b) : a(_a), b(_b) {}

    GMan operator +(const GMan& _b)
    {
         GMan d;
         d.a = this->a + _b.a;
         d.b = this->b + _b.b;
         return d;
    }
};

int main()
{
    GMan d1(1, 2), d(2);
    GMan d3;
    d3 = d1 + 4; 
    d3 = 4 + d1;
}

d1 + 4 works but 4 + d1 doesn't even though 4 can be converted implicitly to a GMan. Why aren't they equivalent?

struct GMan
{
    int a, b;

    GMan() : a(), b() {}
    GMan(int _a) : a(_a), b() {}
    GMan(int _a, int _b) : a(_a), b(_b) {}

    GMan operator +(const GMan& _b)
    {
         GMan d;
         d.a = this->a + _b.a;
         d.b = this->b + _b.b;
         return d;
    }
};

int main()
{
    GMan d1(1, 2), d(2);
    GMan d3;
    d3 = d1 + 4; 
    d3 = 4 + d1;
}

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

花辞树 2024-10-09 20:24:58

调用 x + y 由 C++ 编译器翻译为以下两个调用之一(取决于 x 是否为类类型,以及是否存在这样的函数):

  1. 会员功能

    x.operator +(y);
    
  2. 自由函数

    运算符 +(x, y);
    

现在,C++ 有一个简单的规则:在成员访问运算符 (.) 之前不能发生隐式转换。这样,上面代码中的 x 就无法在第一个代码中进行隐式转换,但在第二个代码中可以。

这个规则是有道理的:如果 x 可以在上面的第一个代码中隐式转换,C++ 编译器将不再知道要调用哪个函数(即它属于哪个类),因此它必须在所有现有类中搜索匹配的成员函数。这会对 C++ 的类型系统造成严重破坏,并使重载规则变得更加复杂和混乱。

A call x + y is translated by the C++ compiler into either of the following two calls (depending on whether x is of class type, and whether such a function exists):

  1. Member function

    x.operator +(y);
    
  2. Free function

    operator +(x, y);
    

Now C++ has a simple rule: no implicit conversion can happen before a member access operator (.). That way, x in the above code cannot undergo an implicit conversion in the first code, but it can in the second.

This rule makes sense: if x could be converted implicitly in the first code above, the C++ compiler wouldn’t know any more which function to call (i.e. which class it belongs to) so it would have to search all existing classes for a matching member function. That would play havoc with C++’ type system and make the overloading rules even more complex and confusing.

心房的律动 2024-10-09 20:24:58

这个答案是正确的。这些要点需要实现此类运算符的规范方法:

struct GMan
{
    int a, b;

    /* Side-note: these could be combined:
    GMan():a(),b(){}
    GMan(int _a):a(_a),b(){}
    GMan(int _a, int _b):a(_a),b(_b){}
    */
    GMan(int _a = 0, int _b = 0) : a(_a), b(_b){} // into this

    // first implement the mutating operator
    GMan& operator+=(const GMan& _b)
    {
        // the use of 'this' to access members
        // is generally seen as noise
        a += _b.a;
        b += _b.b;

        return *this;
    }
};

// then use it to implement the non-mutating operator, as a free-function
// (always prefer free-functions over member-functions, for various reasons)
GMan operator+(GMan _a, const GMan& _b)
{
    _a += b; // code re-use
    return _a;
}

对于其他运算符,依此类推。

This answer is correct. Those points then entail the canonical way of implementing such operators:

struct GMan
{
    int a, b;

    /* Side-note: these could be combined:
    GMan():a(),b(){}
    GMan(int _a):a(_a),b(){}
    GMan(int _a, int _b):a(_a),b(_b){}
    */
    GMan(int _a = 0, int _b = 0) : a(_a), b(_b){} // into this

    // first implement the mutating operator
    GMan& operator+=(const GMan& _b)
    {
        // the use of 'this' to access members
        // is generally seen as noise
        a += _b.a;
        b += _b.b;

        return *this;
    }
};

// then use it to implement the non-mutating operator, as a free-function
// (always prefer free-functions over member-functions, for various reasons)
GMan operator+(GMan _a, const GMan& _b)
{
    _a += b; // code re-use
    return _a;
}

And so on for other operators.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文