为什么虚拟赋值的行为与相同签名的其他虚拟函数不同?
在尝试实现虚拟赋值运算符时,我以一个有趣的行为结束了。 这不是编译器故障,因为 g++ 4.1、4.3 和 VS 2005 具有相同的行为。
基本上,就实际执行的代码而言,虚拟运算符= 的行为与任何其他虚拟函数不同。
struct Base {
virtual Base& f( Base const & ) {
std::cout << "Base::f(Base const &)" << std::endl;
return *this;
}
virtual Base& operator=( Base const & ) {
std::cout << "Base::operator=(Base const &)" << std::endl;
return *this;
}
};
struct Derived : public Base {
virtual Base& f( Base const & ) {
std::cout << "Derived::f(Base const &)" << std::endl;
return *this;
}
virtual Base& operator=( Base const & ) {
std::cout << "Derived::operator=( Base const & )" << std::endl;
return *this;
}
};
int main() {
Derived a, b;
a.f( b ); // [0] outputs: Derived::f(Base const &) (expected result)
a = b; // [1] outputs: Base::operator=(Base const &)
Base & ba = a;
Base & bb = b;
ba = bb; // [2] outputs: Derived::operator=(Base const &)
Derived & da = a;
Derived & db = b;
da = db; // [3] outputs: Base::operator=(Base const &)
ba = da; // [4] outputs: Derived::operator=(Base const &)
da = ba; // [5] outputs: Derived::operator=(Base const &)
}
其效果是,虚拟运算符= 与具有相同签名的任何其他虚拟函数([0] 与 [1] 相比)具有不同的行为,通过在通过实际派生对象调用时调用该运算符的基本版本 ([1] )或派生引用([3]),而当通过基引用([2])调用时,或者当左值或右值是基引用而另一个是派生引用([4], [5])。
对于这种奇怪的行为有任何合理的解释吗?
While playing with implementing a virtual assignment operator I have ended with a funny behavior. It is not a compiler glitch, since g++ 4.1, 4.3 and VS 2005 share the same behavior.
Basically, the virtual operator= behaves differently than any other virtual function with respect to the code that is actually being executed.
struct Base {
virtual Base& f( Base const & ) {
std::cout << "Base::f(Base const &)" << std::endl;
return *this;
}
virtual Base& operator=( Base const & ) {
std::cout << "Base::operator=(Base const &)" << std::endl;
return *this;
}
};
struct Derived : public Base {
virtual Base& f( Base const & ) {
std::cout << "Derived::f(Base const &)" << std::endl;
return *this;
}
virtual Base& operator=( Base const & ) {
std::cout << "Derived::operator=( Base const & )" << std::endl;
return *this;
}
};
int main() {
Derived a, b;
a.f( b ); // [0] outputs: Derived::f(Base const &) (expected result)
a = b; // [1] outputs: Base::operator=(Base const &)
Base & ba = a;
Base & bb = b;
ba = bb; // [2] outputs: Derived::operator=(Base const &)
Derived & da = a;
Derived & db = b;
da = db; // [3] outputs: Base::operator=(Base const &)
ba = da; // [4] outputs: Derived::operator=(Base const &)
da = ba; // [5] outputs: Derived::operator=(Base const &)
}
The effect is that the virtual operator= has a different behavior than any other virtual function with the same signature ([0] compared to [1]), by calling the Base version of the operator when called through real Derived objects ([1]) or Derived references ([3]) while it does perform as a regular virtual function when called through Base references ([2]), or when either the lvalue or rvalue are Base references and the other a Derived reference ([4],[5]).
Is there any sensible explanation to this odd behavior?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
事情是这样的:
如果我将 [1] 更改为,
那么事情就会按照您期望的方式进行。
Derived
中有一个自动生成的赋值运算符,如下所示:在您的示例中,编译器有足够的信息来猜测
a
和b
的类型派生
,因此他们选择使用上面自动生成的运算符来调用您的运算符。 这就是你得到的[1]。 我的指针转换强制编译器按照您的方式执行操作,因为我告诉编译器“忘记”b
的类型为Derived
,因此它使用Base
>。其他结果可以用同样的方法解释。
Here's how it goes:
If I change [1] to
then things work the way you expect. There's an automatically generated assignment operator in
Derived
that looks like this:In your example compilers have enough info to guess that
a
andb
are of typeDerived
and so they choose to use the automatically generated operator above that calls yours. That's how you got [1]. My pointer casting forces compilers to do it your way, because I tell compiler to "forget" thatb
is of typeDerived
and so it usesBase
.Other results can be explained the same way.
在这种情况下有三个operator=:
这解释了为什么它看起来像Base::operator=(Base const&) 在情况[1]中被“虚拟地”调用。 它是从编译器生成的版本中调用的。 这同样适用于案例[3]。 在情况 2 中,右侧参数 'bb' 的类型为 Base&,因此无法调用 Derived::operator=(Derived&)。
There are three operator= in this case:
This explains why it looks like Base::operator=(Base const&) is called "virtually" in case [1]. It's called from the compiler-generated version. The same applies to case [3]. In case 2, the right-hand side argument 'bb' has type Base&, so Derived::operator=(Derived&) cannot be called.
没有为派生类定义用户提供的赋值运算符。 因此,编译器合成一个,并从派生类的合成赋值运算符调用内部基类赋值运算符。
因此,a = b; // [1] 输出: Base::operator=(Base const &)
在派生类中,基类赋值运算符已被重写,因此,重写的方法在派生类的虚拟表中获取一个条目。 当通过引用或指针调用该方法时,由于运行时的 VTable 条目解析,派生类重写方法将被调用。
==>内部==> (对象->VTable[赋值运算符])
获取对象所属类的VTable中赋值运算符的条目并调用该方法。
There is no user-provided assignment operator defined for Derived class. Hence, compiler synthesizes one and internally base class assignment operator is called from that synthesized assignment operator for Derived class.
Hence,
a = b; // [1] outputs: Base::operator=(Base const &)
In Derived class, the Base class assignment operator has been overridden and hence, the overridden method gets an entry in virtual table of the Derived class. When the method is invoked via reference or pointers then Derived class overridden method gets called due to VTable entry resolution at run time.
==>internally ==> (Object->VTable[Assignement operator])
Get the entry for assignment operator in VTable of the class to which the object belongs and invoke the method.
如果您未能提供适当的
operator=
(即正确的返回值和参数类型),编译器将提供默认的operator=
,它会重载任何用户定义的操作符。 在您的情况下,它将在复制派生成员之前调用Base::operator= (Base const& )
。检查此链接了解详细信息运算符= 被虚拟化。
If you fail to provide an appropriate
operator=
(i.e. correct return and argument types), the defaultoperator=
is provided by the compiler which overloads any user-defined one. In your case it will call theBase::operator= (Base const& )
before copying the Derived members.Check this link for details on operator= being made virtual.
原因是编译器提供了默认赋值
operator=
。这在
a = b
场景中被调用,并且我们知道默认内部调用基本赋值运算符。有关虚拟分配的更多说明,请访问:https://stackoverflow.com/a/26906275/3235055
The reason being there is compiler provided default assignment
operator=
.Which is called in the scenario
a = b
and as we know default internally calls base assignment operator.More explanation about virtual assignment can be found at : https://stackoverflow.com/a/26906275/3235055