规范形式的+ =运算符用于类

I know that it's a good idea to make as much of the interface of a class non-member non-friend as possible, and I've just realised that for my 3D vector class, 'Vector3', I can move the +=, -= and so on operators out of the class, leaving just constructors and the copy assignment operator.

我知道尽可能多地创建类非成员非朋友的界面是个好主意,我刚刚意识到,对于我的3D矢量类'Vector3',我可以移动+ =, - =等等运算符出类,只留下构造函数和复制赋值运算符。

The question is: what should this operator look like? I've seen canonical forms of plenty of other operators and have followed their advice, but I haven't seen canonical forms of these operators. I've given what I think it should be below.

问题是:这个运算符应该是什么样的?我已经看过许多其他运营商的规范形式,并且已经遵循他们的建议,但我还没有看到这些运营商的规范形式。我已经给出了我认为应该在下面的内容。

The secondary question is: what are these operators even called? Arithmetic assignment operators?

第二个问题是:这些运营商甚至被称为什么?算术赋值运算符?

The (relevant) code before:

之前的(相关)代码:

class Vector3 {
public:
    Vector3& operator+=(const Vector3& rhs);
    float x, y, z;
};

Vector3& Vector3::operator+=(const Vector3 &rhs) {
    x += rhs.x;
    y += rhs.y;
    z += rhs.z;

    return *this;
}

What I've changed it to so far:

到目前为止我改变了什么:

class Vector3 {
public:
    float x, y, z;
};

Vector3& operator+=(Vector3& lhs, const Vector3& rhs) {
    lhs.x += rhs.x;
    lhs.y += rhs.y;
    lhs.z += rhs.z;

    return lhs;
}

3 个解决方案

#1

What you have looks good to me.

你有什么看起来对我好。

By the way, when you come to the operator+, it is common to implement that in terms of +=. (create a copy of lhs, and then call lhs += rhs and return the result)

顺便说一下,当你来到运营商+时,通常用+ =来实现。 (创建lhs的副本,然后调用lhs + = rhs并返回结果)

Don't know if you're already aware of this trick, but since you're concerned about canonical ways to implement these operators, it can't hurt to mention it. :)

不知道你是否已经意识到这个技巧,但是由于你担心实现这些操作符的规范方法,所以提起它并不会有什么坏处。 :)

#2

What you have looks good.

你有什么看起来不错。

The basic way to think about this, intuitively, is to think about what you'd like code to look like when you write it. If, in this case, you can write

直观地思考这个问题的基本方法是考虑编写代码时的代码。如果,在这种情况下,你可以写

Vector v, w;

v += w;
w += v;

and so on, you're on the right track.

等等,你走在正确的轨道上。

There are a lot of good rules of thumb to help; see this entry in the C++ FAQ for lots on it.

有很多好的经验法则可以提供帮助;有关它的详细信息,请参阅C ++ FAQ中的此条目。

#3

I wouldn't say "as much of the interface as possible". There isn't much to be gained by making operator+=, operator-= etc. a not-friend not-member.

我不会说“尽可能多的接口”。通过使operator + =,operator- =等成为非朋友非成员,没有多少收获。

Some people prefer to make every function possible a non-member non-friend function to resist the temptation of using private member variables. But you are an adult: you can write the function as a public member, and not use the private member variables. I prefer to know that the function is tied to the class, and making it a public member makes it explicit.

有些人喜欢使每个函数成为非成员非朋友函数来抵制使用私有成员变量的诱惑。但您是成年人:您可以将该函数编写为公共成员,而不是使用私有成员变量。我更喜欢知道函数与类绑定,并使其成为公共成员使其显式化。

Aside note:
Personally, I find that it's often OK to use the private members instead of public accessors (I know -- I'll burn in hell). Not always! -- but often.
In fact, there are few cases where you couldn't make the switch to public accessors in a manner of minutes if you decide you need it. But I recognize it's not a popular view and I don't ask people to follow that philosophy.

除了注意:就个人而言,我发现使用私人成员而不是公共访问者通常是可以的(我知道 - 我会在地狱中燃烧)。不总是! - 但经常。实际上,如果您决定需要,几乎没有情况下您无法以几分钟的方式切换到公共访问者。但我认识到这不是一种流行的观点,我不会要求人们遵循这一理念。

There are concrete reasons to make certaint functions and operators "non-friend, non-member". For example, operator<<() when used as the "stream-insertion operator" cannot be made a member because you would have to change the lhs class (the stream).

具体的理由使确定的功能和操作员“非朋友,非会员”。例如,当用作“流插入运算符”时,operator <<()不能成为成员,因为您必须更改lhs类(流)。

#1