返回对象而不将其暴露给删除 [英] Return object without exposing it to delete
问题描述
大家好，
我在用其他语言编程后回到C ++，并发现
我自己对以下问题感到有些困惑:(见附件代码）。
如何避免删除方法返回的对象？
是否唯一可能返回克隆？对于较大的物体，这将使用大量的
内存。
非常感谢！
Michael
#include< iostream>
使用命名空间std;
class Dummy {
public：
int n;
};
class受害者{
私人：
假人* d;
公众：
受害者（）{
d =新假人（）;
d-> n = 23;
}
Dummy * getDummy（）{
返回d; < br $>
}
};
int main（int argc，char ** argv）{
受害者* v =新受害者（）;
Dummy * d = v-> getDummy（）;
cout<< d-> n<< endl;
删除d;
cout<< d-> n<<结束;
返回0;
}
// EOF
输出：
23
$ div class =h2_lin>解决方案
Michael Pradel写道：
大家好，
我刚用其他语言编程后回到C ++，发现
我自己有点疑惑关于以下问题:(参见附件代码）。
如何避免删除方法返回的对象？
返回a克隆它唯一的可能性？如果是较大的对象，那将使用大量的内存。
您可以将boost :: shared_ptr与nop删除器一起使用。
void noop（）{}
shared_ptr< TgetT（）const {return shared_ptr< T>（t，bind（& noop））; }
但是，我想这可能会导致问题，如果你在哪里完成
使用所有在删除之前有删除器的shared_ptrs
超出了范围。不幸的是，shared_ptr是唯一一个允许你覆盖删除器的
。
1月26日上午8:51，Michael Pradel< mich ... @ binaervarianz.dewrote：
我用其他语言编程后回到C ++，找到
我自己对以下问题感到有些困惑：>
int main（int argc，char ** argv）{
Victim * v = new Victim（）;
Dummy * d = v-> getDummy（）;
cout<< d-> n<< endl;
删除d;
cout<< d-> n<< endl;
返回0;} // EOF
如何避免删除方法返回的对象？ br />
返回它的唯一可能性吗？如果是较大的对象，那将使用大量的内存。
通过简单地观察一个简单的规则：负责分配对象的代码也对该对象的释放负全部责任。在
这种情况下，main（）没有显式（或直接）分配Dummy
对象，d，因此main（）不应该删除 d"
另一方面，main（）确实分配了v，因此main（）应该在退出之前删除v
。删除v应该导致v删除d（因为v是
，负责首先分配d）。
受害者类不会释放其成员的事实应被视为该程序中的一个
错误。
所以通过观察这个关于对象释放的简单约定，每个人最终都会关注自己的事务，没有人会干涉别人的事务。但实际上，C ++
程序应该避免显式的new和delete调用 - 而是依赖于shared_ptr'或auto_ptr'上的
来管理对象代表它的生命。
Greg
Michael Pradel< mi ***** @ binaervarianz。 dewrote：
我在用其他语言编程后回到C ++，并发现
我对以下问题有点疑惑:(见附加代码）。
如何避免删除方法返回的对象？
通过记录谁负责删除对象。我这样做的方式就是当我不希望他们删除
对象和指针时返回引用。 （是的，他们仍然可以删除对象，
但是在文档中我告诉他们不要这样做，所以他们要么不知道，或者他们是无知。）
返回克隆是唯一的可能吗？
或者根本不让他们访问它。
Hi all,
I just returned to C++ after programming in other languages, and find
myself a bit puzzled about the following issue: (see attached code).
How can I avoid the deletion of an object that is returned by a method?
Is returning a clone of it the only possibility? That would use a lot of
memory in case of larger objects.
Thanks a lot!
Michael
#include <iostream>
using namespace std;
class Dummy {
public:
int n;
};
class Victim {
private:
Dummy *d;
public:
Victim() {
d = new Dummy();
d->n = 23;
}
Dummy* getDummy() {
return d;
}
};
int main(int argc, char **argv) {
Victim *v = new Victim();
Dummy *d = v->getDummy();
cout << d->n << endl;
delete d;
cout << d->n << endl;
return 0;
}
// EOF
Output:
23
0
Michael Pradel wrote:Hi all,
I just returned to C++ after programming in other languages, and find
myself a bit puzzled about the following issue: (see attached code).
How can I avoid the deletion of an object that is returned by a method?
Is returning a clone of it the only possibility? That would use a lot of
memory in case of larger objects.You could use boost::shared_ptr with a nop deleter.
void noop() {}
shared_ptr<TgetT() const { return shared_ptr<T>(t, bind(&noop)); }
However, I imagine this could cause problems if you where to finish
using all the shared_ptrs that have deleters before this returned one
went out of scope. Unfortunately shared_ptr is the only one that
appears to let you override the deleter.
On Jan 26, 8:51 am, Michael Pradel <mich...@binaervarianz.dewrote:I just returned to C++ after programming in other languages, and find
myself a bit puzzled about the following issue: >
int main(int argc, char **argv) {
Victim *v = new Victim();
Dummy *d = v->getDummy();
cout << d->n << endl;
delete d;
cout << d->n << endl;
return 0;}// EOF
How can I avoid the deletion of an object that is returned by a method?
Is returning a clone of it the only possibility? That would use a lot of
memory in case of larger objects.By simply observing a simple rule: the code responsible for allocating
an object is also solely responsible for that object''s deallocation. In
this case, main() did not explicitly (or directly) allocate the Dummy
object, "d", so main() should not be deleting "d".
On the other hand, main() did allocate "v'', so main() should delete v
before it exits. Deleting v should cause v to delete d (since v was
responsible for allocating d in the first place). The fact that the
Victim class does not deallocate its d member should be considered a
bug in the program.
So by observing this simple convention regarding object deallocation,
everyone ends up minding their own affairs and no one interferes with
the affairs of anyone else. As a practical matter, though, a C++
program should avoid explicit new and delete calls - and instead rely
on shared_ptr''s or auto_ptr''s to manage object lifetimes on its behalf.
Greg
Michael Pradel <mi*****@binaervarianz.dewrote:
I just returned to C++ after programming in other languages, and find
myself a bit puzzled about the following issue: (see attached code).
How can I avoid the deletion of an object that is returned by a method?By documenting who is responsible for the object''s deletion. The way I
do that is by returning a reference when I don''t want them to delete the
object and a pointer when I do. (Yes they could still delete the object,
but in the documentation I''ve told them not to do it, so they either
know not to, or they are ignorant.)
Is returning a clone of it the only possibility?That or simply not giving them access to it.
这篇关于返回对象而不将其暴露给删除的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
