auto_ptr always implies heap?

Discussion in 'C++' started by swengtoo, Dec 16, 2005.

  1. swengtoo

    swengtoo Guest

    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!
     
    swengtoo, Dec 16, 2005
    #1
    1. Advertising

  2. swengtoo

    mlimber Guest

    swengtoo wrote:
    > 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
     
    mlimber, Dec 16, 2005
    #2
    1. Advertising

  3. swengtoo

    swengtoo Guest

    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?
     
    swengtoo, Dec 16, 2005
    #3
  4. swengtoo

    mlimber Guest

    swengtoo wrote:
    > 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
     
    mlimber, Dec 16, 2005
    #4
  5. swengtoo wrote:
    > [..]
    > 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
     
    Victor Bazarov, Dec 16, 2005
    #5
  6. swengtoo

    swengtoo Guest

    Victor Bazarov wrote:
    > 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.
     
    swengtoo, Dec 16, 2005
    #6
  7. swengtoo wrote:
    > Victor Bazarov wrote:
    >
    >>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.),


    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
     
    Victor Bazarov, Dec 16, 2005
    #7
  8. swengtoo

    swengtoo Guest

    Victor Bazarov wrote:
    > 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.
     
    swengtoo, Dec 16, 2005
    #8
  9. swengtoo

    mlimber Guest

    swengtoo wrote:
    > Victor Bazarov wrote:
    > > 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.

    [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
     
    mlimber, Dec 16, 2005
    #9
  10. "swengtoo" <> wrote in message
    news:...

    > 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
     
    =?iso-8859-1?Q?Ali_=C7ehreli?=, Dec 17, 2005
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Siemel Naran

    auto_ptr<Derived> to auto_ptr<Base>

    Siemel Naran, Jan 10, 2005, in forum: C++
    Replies:
    2
    Views:
    1,584
    Dave Rahardja
    Jan 11, 2005
  2. teo
    Replies:
    2
    Views:
    369
    kferron
    Dec 10, 2006
  3. Plasmafire
    Replies:
    1
    Views:
    7,813
    Thomas Fritsch
    Jun 19, 2007
  4. Michal Slocinski

    Heap dump file size vs heap size

    Michal Slocinski, Mar 25, 2008, in forum: Java
    Replies:
    1
    Views:
    772
    GArlington
    Mar 25, 2008
  5. Sousuke
    Replies:
    9
    Views:
    1,184
    Bart van Ingen Schenau
    Mar 16, 2010
Loading...

Share This Page