auto_ptr always implies heap?

[swengtoo]

My understanding is that an auto_ptr can never own an object that was
created on the stack. This is because when auto_ptr goes out of scope,
it calls 'delete' for the object it points to.

Is my understanding correct? Or did I miss anything here?

Thanks!

 

[mlimber]

My understanding is that an auto_ptr can never own an object that was
created on the stack. This is because when auto_ptr goes out of scope,
it calls 'delete' for the object it points to.

Is my understanding correct? Or did I miss anything here?

Thanks!

Close. An object held by an auto_ptr can be allocated anywhere as long
as it can be deleted. (Recall that you can overload the delete operator
to do custom allocation.)

Cheers! --M

 

[swengtoo]

Wow! thanks for the quick and clarifying answer.

So, if I understand your answer correctly, it is possible to call
'delete' for an object that was allocated on the stack - if its delete
operator was overloaded to do this kind of magic. Correct?

If so, can you bring an example of a scenario that would prompt a
programmer to overload delete so that it operates on stack objects?

 

[mlimber]

Wow! thanks for the quick and clarifying answer.

No problem. Please quote the post you're responding to. (If you're
using Google Groups, click "show options" and then "Reply" in the
revealed header.)

So, if I understand your answer correctly, it is possible to call
'delete' for an object that was allocated on the stack - if its delete
operator was overloaded to do this kind of magic. Correct?
Yes.

If so, can you bring an example of a scenario that would prompt a
programmer to overload delete so that it operates on stack objects?

Well, far more common (and utile) are memory pools. See this FAQ:

http://www.parashift.com/c++-faq-lite/dtors.html#faq-11.14

Cheers! --M

 

[Victor Bazarov]

[..]
If so, can you bring an example of a scenario that would prompt a
programmer to overload delete so that it operates on stack objects?

Not on stack objects ("automatic" is the actual term) but on static ones,
I guess. Especially if you work in a system that doesn't have a "heap"
("free store" is the actual term). Besides, indirect allocation/freeing
is also a possibility: once a global pool of objects is allocated, then
each of them is "allocated" in and "deleted" from that pool. The generic
pool in that case is the free store. The generic mechanism is the default
'new' and 'delete'. You can customize them to write your own pool-based
memory manager to reduce "heap fragmentation", for example.

V

 

[swengtoo]

Not on stack objects ("automatic" is the actual term) but on static ones,
I guess. Especially if you work in a system that doesn't have a "heap"
("free store" is the actual term). Besides, indirect allocation/freeing
is also a possibility: once a global pool of objects is allocated, then
each of them is "allocated" in and "deleted" from that pool. The generic
pool in that case is the free store. The generic mechanism is the default
'new' and 'delete'. You can customize them to write your own pool-based
memory manager to reduce "heap fragmentation", for example.

I am familiar with allocation "in place" (placement new, etc.), but the
idea of oveloading the delete operator to operate on stack objects
(automatic variables) was pretty new to me. After all, if the automatic
object is deleted automatically once it goes out of scope, why
complicate matters?

One could argue that I would want to implement something like that
exactly for the original idea that started this thread: letting an
auto_ptr point to an automatic variable. But then, is this the most
elegant solution to the "problem"? Are there other scenarios that would
mandate overriding delete to work on a stack object?

Thanks.

 

[Victor Bazarov]

I am familiar with allocation "in place" (placement new, etc.),

How is that relevant here?

> but the
idea of oveloading the delete operator to operate on stack objects
(automatic variables) was pretty new to me. After all, if the automatic
object is deleted automatically once it goes out of scope, why
complicate matters?

I am not sure where you're coming from about "complicating matters". You
started with 'auto_ptr' owning an automatic object, which is theoretically
allowed if that class defines 'delete' in a certain way. There is no
sense AFAIK to do that in a _real_life_ program. I've not encountered it
in my 10+ years of C++.

One could argue that I would want to implement something like that
exactly for the original idea that started this thread: letting an
auto_ptr point to an automatic variable. But then, is this the most
elegant solution to the "problem"?

What is <<the "problem">> you're referring to? It seems that allowing
'auto_ptr' to hold the address of an automatic variable is what is known
as "a solution in search of a problem". What would be the reason for you
to create an auto_ptr object and let it hold the address of an automatic
object?

> Are there other scenarios that would
mandate overriding delete to work on a stack object?

Since you are speaking hypothetically, anyway, here is one: I would
override 'new' and 'delete' and make them throw just to prohibit any
allocation of those objects in the free store. This is not usual by any
measures.

V

 

[swengtoo]

What is <<the "problem">> you're referring to? It seems that allowing
'auto_ptr' to hold the address of an automatic variable is what is known
as "a solution in search of a problem". What would be the reason for you
to create an auto_ptr object and let it hold the address of an automatic
object?

I ran into a situation in which I wanted to pass the pointer of an
automatic variable to a class which internally uses auto_ptr to store
it. I guess this points to a fundamentally flawed design. I will have
to re-think.

Since you are speaking hypothetically, anyway, here is one: I would
override 'new' and 'delete' and make them throw just to prohibit any
allocation of those objects in the free store. This is not usual by any
measures.

Thanks. You answered my question.

 

[mlimber]

I ran into a situation in which I wanted to pass the pointer of an
automatic variable to a class which internally uses auto_ptr to store
it. I guess this points to a fundamentally flawed design. I will have
to re-think.

[snip]

Right. According to common usage, a class that accepts an auto_ptr
takes over ownership of that object. Therefore, you must pass an object
that is delete-able (which usually means that the object was
dynamically allocated in free store). If you are trying to pass an
automatic variable to that class, you are misusing the class.

Cheers! --M

 

[=?iso-8859-1?Q?Ali_=C7ehreli?=]

I ran into a situation in which I wanted to pass the pointer of an
automatic variable to a class which internally uses auto_ptr to store
it. I guess this points to a fundamentally flawed design. I will have
to re-think.

Did you handle the copy constructor for the class that had the auto_ptr as a
member? It must have been ugly because the copy constructor of the auto_ptr
does not copy.

I think auto_ptr is accepted to be useful only in transfer of ownership when
calling functions. It can be used in other situations as well, but always
with risks and in awkward ways.

I would bring in Boost's smart pointers and start using them today!

Ali