Doubt regarding memory deallocation...

Discussion in 'C++' started by Sachin Midha, Sep 11, 2010.

  1. Sachin Midha

    Sachin Midha Guest

    Hi,
    I just saw someone code something like this...
    int y;
    class a{
    public:
    int x;
    void f(){
    y=1;
    delete this;
    g();
    x=5;
    }
    void g(){}
    };

    Can someone please let me know what consequences would {delete this}
    have on the code following that line?
    What I feel is that, since functions are not allocated memory(shared
    between all the objects of a class), call to g() would be done
    successfully, but the code x=5, would cause a segmentation fault,
    since it has no memory allocated(since object has been deleted).
    But then, somebody told me that if I look at the assembly level,
    delete calls a routine, and when it returns, it is lost & causes a
    crash in the application. So, I am really confused, please help me
    understand this.

    Thanks,
    Sachin
     
    Sachin Midha, Sep 11, 2010
    #1
    1. Advertising

  2. Sachin Midha <> wrote:
    > but the code x=5, would cause a segmentation fault


    Actually in most systems it wouldn't. Just because you delete an object
    doesn't mean that the memory block where the object was will be released
    to the operating system by the memory allocator. (A segmentation fault
    happens if a process tries to access memory that it didn't get from the OS.)

    It's still undefined behavior, though, so anything could happen.
     
    Juha Nieminen, Sep 11, 2010
    #2
    1. Advertising

  3. Sachin Midha

    Sachin Midha Guest

    On Sep 11, 1:51 pm, Juha Nieminen <> wrote:
    > Sachin Midha <> wrote:
    > > but the code x=5, would cause a segmentation fault

    >
    >   Actually in most systems it wouldn't. Just because you delete an object
    > doesn't mean that the memory block where the object was will be released
    > to the operating system by the memory allocator. (A segmentation fault
    > happens if a process tries to access memory that it didn't get from the OS.)
    >
    >   It's still undefined behavior, though, so anything could happen.


    On Sep 11, 1:51 pm, Juha Nieminen <> wrote:
    > Sachin Midha <> wrote:
    > > but the code x=5, would cause a segmentation fault

    >
    >   Actually in most systems it wouldn't. Just because you delete an object
    > doesn't mean that the memory block where the object was will be released
    > to the operating system by the memory allocator. (A segmentation fault
    > happens if a process tries to access memory that it didn't get from the OS.)
    >
    >   It's still undefined behavior, though, so anything could happen.


    Deleting an object does not mean releasing the allocated block...???
    can you please explain this, and if not on deleting, then when does
    the allocated block be released...??
     
    Sachin Midha, Sep 11, 2010
    #3
  4. Sachin Midha

    Kai-Uwe Bux Guest

    Sachin Midha wrote:

    > On Sep 11, 1:51 pm, Juha Nieminen <> wrote:
    >> Sachin Midha <> wrote:
    >> > but the code x=5, would cause a segmentation fault

    >>
    >> Actually in most systems it wouldn't. Just because you delete an object
    >> doesn't mean that the memory block where the object was will be released
    >> to the operating system by the memory allocator. (A segmentation fault
    >> happens if a process tries to access memory that it didn't get from the
    >> OS.)
    >>
    >> It's still undefined behavior, though, so anything could happen.

    >
    > On Sep 11, 1:51 pm, Juha Nieminen <> wrote:
    >> Sachin Midha <> wrote:
    >> > but the code x=5, would cause a segmentation fault

    >>
    >> Actually in most systems it wouldn't. Just because you delete an object
    >> doesn't mean that the memory block where the object was will be released
    >> to the operating system by the memory allocator. (A segmentation fault
    >> happens if a process tries to access memory that it didn't get from the
    >> OS.)
    >>
    >> It's still undefined behavior, though, so anything could happen.

    >
    > Deleting an object does not mean releasing the allocated block...???
    > can you please explain this, and if not on deleting, then when does
    > the allocated block be released...??


    Note the operative words "released _to_the_operating_system_". Calling
    delete surely "releases" the memory, but only in the sense that subsequence
    calls to new might use that memory. Whether the OS gets that memory back is
    not specified by the standard. In fact, the standard is well-advised to take
    the stance that the OS might be lacking system calls for returning memory.


    Best

    Kai-Uwe Bux
     
    Kai-Uwe Bux, Sep 11, 2010
    #4
  5. Sachin Midha

    Öö Tiib Guest

    On 11 sept, 21:14, Sachin Midha <> wrote:
    > On Sep 11, 1:51 pm, Juha Nieminen <> wrote:
    >
    > > Sachin Midha <> wrote:
    > > > but the code x=5, would cause a segmentation fault

    >
    > >   Actually in most systems it wouldn't. Just because you delete an object
    > > doesn't mean that the memory block where the object was will be released
    > > to the operating system by the memory allocator. (A segmentation fault
    > > happens if a process tries to access memory that it didn't get from the OS.)

    >
    > >   It's still undefined behavior, though, so anything could happen.

    >
    > Deleting an object does not mean releasing the allocated block...???
    > can you please explain this, and if not on deleting, then when does
    > the allocated block be released...??


    Deleting an object does mean it is destroyed and storage of it is
    released for your code.

    Attempts to access it after deletion are undefined behavior. Undefined
    behavior means that it is not defined what happens. There are no
    guarantees that it works nor are there guarantees that you get access
    violation errors or something. It is your responsibility to not do it.
    Computer does not need to waste its resources to check if you are
    stupid, it assumes you are not since you are programmer.
     
    Öö Tiib, Sep 11, 2010
    #5
  6. Sachin Midha

    Sachin Midha Guest

    On Sep 11, 11:31 pm, Öö Tiib <> wrote:
    > On 11 sept, 21:14, Sachin Midha <> wrote:
    >
    > > On Sep 11, 1:51 pm, Juha Nieminen <> wrote:

    >
    > > > Sachin Midha <> wrote:
    > > > > but the code x=5, would cause a segmentation fault

    >
    > > >   Actually in most systems it wouldn't. Just because you delete an object
    > > > doesn't mean that the memory block where the object was will be released
    > > > to the operating system by the memory allocator. (A segmentation fault
    > > > happens if a process tries to access memory that it didn't get from the OS.)

    >
    > > >   It's still undefined behavior, though, so anything could happen.

    >
    > > Deleting an object does not mean releasing the allocated block...???
    > > can you please explain this, and if not on deleting, then when does
    > > the allocated block be released...??

    >
    > Deleting an object does mean it is destroyed and storage of it is
    > released for your code.
    >
    > Attempts to access it after deletion are undefined behavior. Undefined
    > behavior means that it is not defined what happens. There are no
    > guarantees that it works nor are there guarantees that you get access
    > violation errors or something. It is your responsibility to not do it.
    > Computer does not need to waste its resources to check if you are
    > stupid, it assumes you are not since you are programmer.


    Ok...thanks a lot for this.

    This means that the code would execute but the behavior is undefined,
    this means whatever modifications we do in the code after delete(this)
    would occur..e.g. if I modify the value of any global variable, they
    would be updated. Right?

    Thanks.
     
    Sachin Midha, Sep 12, 2010
    #6
  7. Sachin Midha

    Bo Persson Guest

    Sachin Midha wrote:
    > On Sep 11, 11:31 pm, Öö Tiib <> wrote:
    >> On 11 sept, 21:14, Sachin Midha <> wrote:
    >>
    >>> On Sep 11, 1:51 pm, Juha Nieminen <> wrote:

    >>
    >>>> Sachin Midha <> wrote:
    >>>>> but the code x=5, would cause a segmentation fault

    >>
    >>>> Actually in most systems it wouldn't. Just because you delete an
    >>>> object doesn't mean that the memory block where the object was
    >>>> will be released
    >>>> to the operating system by the memory allocator. (A segmentation
    >>>> fault happens if a process tries to access memory that it didn't
    >>>> get from the OS.)

    >>
    >>>> It's still undefined behavior, though, so anything could happen.

    >>
    >>> Deleting an object does not mean releasing the allocated
    >>> block...??? can you please explain this, and if not on deleting,
    >>> then when does the allocated block be released...??

    >>
    >> Deleting an object does mean it is destroyed and storage of it is
    >> released for your code.
    >>
    >> Attempts to access it after deletion are undefined behavior.
    >> Undefined behavior means that it is not defined what happens.
    >> There are no guarantees that it works nor are there guarantees
    >> that you get access violation errors or something. It is your
    >> responsibility to not do it. Computer does not need to waste its
    >> resources to check if you are stupid, it assumes you are not since
    >> you are programmer.

    >
    > Ok...thanks a lot for this.
    >
    > This means that the code would execute but the behavior is
    > undefined,
    > this means whatever modifications we do in the code after
    > delete(this)
    > would occur..e.g. if I modify the value of any global variable, they
    > would be updated. Right?
    >


    No, we don't know what would happen. Undefined behavior means that
    ANYTHING can happen, including a crash, the program continuing, or
    random effects each time.


    Bo Persson
     
    Bo Persson, Sep 12, 2010
    #7
  8. Sachin Midha

    Default User Guest

    "Sachin Midha" <> wrote in message
    news:...

    > This means that the code would . . .



    There is no defined behavior for undefined behavior.




    Brian
    --
    Day 586 of the "no grouchy usenet posts" project.
     
    Default User, Sep 13, 2010
    #8
    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. qazmlp
    Replies:
    1
    Views:
    747
    John Harrison
    Mar 7, 2004
  2. Replies:
    2
    Views:
    727
    Paavo Helde
    Dec 18, 2004
  3. BigBrian
    Replies:
    12
    Views:
    590
    Pete Becker
    Apr 7, 2005
  4. Nicolas Matringe

    std.textio, readline and memory deallocation

    Nicolas Matringe, Sep 1, 2006, in forum: VHDL
    Replies:
    9
    Views:
    2,104
    Paul Uiterlinden
    Sep 4, 2006
  5. vaysagekv

    Doubt on memmory deallocation

    vaysagekv, Sep 9, 2012, in forum: C Programming
    Replies:
    3
    Views:
    322
    vaysagekv
    Sep 9, 2012
Loading...

Share This Page