Return object without exposing it to delete

[Michael Pradel]

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

[Noah Roberts]

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_p tr with a nop deleter.

void noop() {}

shared_ptr<Tget T() 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.

[Greg]

On Jan 26, 8:51 am, Michael Pradel <mich...@binaer varianz.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

[Daniel T.]

Michael Pradel <mi*****@binaer varianz.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.

[Daniel T.]

In article <ep**********@a ioe.org>, Noah Roberts <us**@example.n et>
wrote:

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_p tr with a nop deleter.

void noop() {}

shared_ptr<Tget T() const { return shared_ptr<T>(t , bind(&noop)); }

delete &*getT();

[JLS]

On Jan 26, 1:42 pm, "Daniel T." <danie...@earth link.netwrote:

In article <epdc6p$is...@a ioe.org>, Noah Roberts <u...@example.n et>
wrote:

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_p tr with a nop deleter.

void noop() {}

shared_ptr<Tget T() const { return shared_ptr<T>(t , bind(&noop)); }delete &*getT();

What about returning a const ptr. Shouldn't that prevent the deletion?

May be of limited usefullness, but it is one way of solving the
problem. You could also make the destructor private and control who can
delete the object.

[Michael Pradel]

By simply observing a simple rule: the code responsible for allocating

an object is also solely responsible for that object's deallocation.

That's a good solution for most of the cases, but e.g. using the Factory
Method design pattern it doesn't make sense. Here one class is only
responsible for creating the object while another will use it and knowns
when to delete it.

Product* Factory::create (ProductID id) {
if (id == A) return new ProductA;
// ...
}

That's one of the examples why I am looking for a general way to
distinguish the case where the using class may delete the returned
object and the case where it shouldn't.
Michael

[Michael Pradel]

What about returning a const ptr. Shouldn't that prevent the deletion?

You mean the following?

const Dummy* getDummy() {
return d;
}
That doesn't work. The deletion works nevertheless.
Michael

[Clark S. Cox III]

JLS wrote:

>
On Jan 26, 1:42 pm, "Daniel T." <danie...@earth link.netwrote:

>In article <epdc6p$is...@a ioe.org>, Noah Roberts <u...@example.n et>
wrote:

>>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_p tr with a nop deleter.
void noop() {}
shared_ptr<Tg etT() const { return shared_ptr<T>(t , bind(&noop)); }delete &*getT();

What about returning a const ptr. Shouldn't that prevent the deletion?

Nope.
--
Clark S. Cox III
cl*******@gmail .com

[Pete Becker]

Noah Roberts wrote:

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_p tr with a nop deleter.

void noop() {}

shared_ptr<Tget T() const { return shared_ptr<T>(t , bind(&noop)); }

void noop(void*){}
return shared_ptr<T>(t , 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.

Not if the code is using shared_ptr correctly. It should create a
shared_ptr object that manages the newly created T object. Everything
that needs the T object gets a copy of that shared_ptr. But in that
case, the noop deleter is wrong: the last shared_ptr object should
delete the object.

The real problem is that you can't dictate application-level policies
with low-level classes. If somebody wants to go out of their way to
delete something that they're not supposed to delete, there's not much
you can do about it. So don't bother.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)