在c++中,什么是对象切片,什么时候发生?
当前回答
切片问题很严重,因为它会导致内存损坏,而且很难保证程序不会受到这种问题的困扰。要用语言设计它,支持继承的类应该只能通过引用(而不是通过值)访问。D编程语言具有此属性。
考虑从A派生的类A和类B。如果A部分有一个指针p,而B实例指向B的附加数据,则可能发生内存损坏。然后,当附加数据被切片时,p指向垃圾。
其他回答
1.切片问题的定义
如果D是基类B的派生类,则可以将派生类型的对象分配给base类型的变量(或参数)。
例子
class Pet
{
public:
string name;
};
class Dog : public Pet
{
public:
string breed;
};
int main()
{
Dog dog;
Pet pet;
dog.name = "Tommy";
dog.breed = "Kangal Dog";
pet = dog;
cout << pet.breed; //ERROR
尽管上面的赋值是允许的,但赋值给变量宠物的值将丢失其品种字段。这被称为切片问题。
2.如何解决切片问题
为了解决这个问题,我们使用指向动态变量的指针。
例子
Pet *ptrP;
Dog *ptrD;
ptrD = new Dog;
ptrD->name = "Tommy";
ptrD->breed = "Kangal Dog";
ptrP = ptrD;
cout << ((Dog *)ptrP)->breed;
在这种情况下,没有动态变量的数据成员或成员函数被ptrD(后代类对象)指向的对象将丢失。此外,如果需要使用函数,则函数必须是虚拟函数。
这些都是很好的答案。我只想在按值传递对象与按引用传递对象时添加一个执行示例:
#include <iostream>
using namespace std;
// Base class
class A {
public:
A() {}
A(const A& a) {
cout << "'A' copy constructor" << endl;
}
virtual void run() const { cout << "I am an 'A'" << endl; }
};
// Derived class
class B: public A {
public:
B():A() {}
B(const B& a):A(a) {
cout << "'B' copy constructor" << endl;
}
virtual void run() const { cout << "I am a 'B'" << endl; }
};
void g(const A & a) {
a.run();
}
void h(const A a) {
a.run();
}
int main() {
cout << "Call by reference" << endl;
g(B());
cout << endl << "Call by copy" << endl;
h(B());
}
输出为:
Call by reference
I am a 'B'
Call by copy
'A' copy constructor
I am an 'A'
所以为什么丢失派生信息很糟糕。。。因为派生类的作者可能已经改变了表示方式,使得分割额外信息改变了对象所表示的值。如果派生类用于缓存对某些操作更有效但转换回基表示代价高昂的表示,则会发生这种情况。
还认为有人应该提到你应该做什么来避免切片。。。获取C++编码标准、101条规则指南和最佳实践的副本。处理切片是#54。
它提出了一种有点复杂的模式来完全解决这个问题:有一个受保护的复制构造函数、一个受受保护的纯虚拟DoClone,以及一个带有断言的公共克隆,如果(进一步)派生类未能正确实现DoClone,该断言将告诉您。(克隆方法对多态对象进行适当的深度复制。)
您还可以在基显式上标记复制构造函数,如果需要,它允许显式切片。
切片问题很严重,因为它会导致内存损坏,而且很难保证程序不会受到这种问题的困扰。要用语言设计它,支持继承的类应该只能通过引用(而不是通过值)访问。D编程语言具有此属性。
考虑从A派生的类A和类B。如果A部分有一个指针p,而B实例指向B的附加数据,则可能发生内存损坏。然后,当附加数据被切片时,p指向垃圾。
在我看来,除了你自己的类和程序架构/设计不好之外,切片并不是什么问题。
如果我将一个子类对象作为参数传递给一个方法,该方法接受一个超类类型的参数,那么我当然应该意识到这一点,并且知道在内部,被调用的方法只能使用超类(也称为基类)对象。
在我看来,提供一个请求基类的子类会导致子类特定的结果,这似乎只是一个不合理的期望,会导致切片成为一个问题。它要么在方法的使用上设计糟糕,要么子类实现糟糕。我猜这通常是牺牲了良好的OOP设计,而为了方便或提高性能的结果。