Why does "delete" not delete?

Discussion in 'C++' started by D. Susman, Mar 10, 2008.

  1. D. Susman

    D. Susman Guest

    Hi,

    When I call "clean" as shown below, shouldn't I be getting
    segmentation fault due to garbage data? I am compiling with CC and the
    output is 5. Does "delete" not delete in this situation or is it no
    guarantee that it will print 5 or go wrong?

    void clean( int* ptr )
    {
    delete ptr;
    }

    //...

    int* ptr = new int( 5 );

    clean( ptr );

    cout << *ptr << endl;
     
    D. Susman, Mar 10, 2008
    #1
    1. Advertising

  2. D. Susman

    Guest

    On Mar 10, 5:11 pm, "D. Susman" <> wrote:
    > Hi,
    >
    > When I call "clean" as shown below, shouldn't I be getting
    > segmentation fault due to garbage data? I am compiling with CC and the
    > output is 5. Does "delete" not delete in this situation or is it no
    > guarantee that it will print 5 or go wrong?
    >
    > void clean( int* ptr )
    > {
    > delete ptr;
    >
    > }
    >
    > //...
    >
    > int* ptr = new int( 5 );
    >
    > clean( ptr );
    >
    > cout << *ptr << endl;


    It is 'undefined behaviour', so the result may vary from one
    implementation to another, and on different runs of the same program.

    Regards.
     
    , Mar 10, 2008
    #2
    1. Advertising

  3. D. Susman

    D. Susman Guest

    On Mar 10, 6:20 pm, wrote:
    > On Mar 10, 5:11 pm, "D. Susman" <> wrote:
    >
    >
    >
    > > Hi,

    >
    > > When I call "clean" as shown below, shouldn't I be getting
    > > segmentation fault due to garbage data? I am compiling with CC and the
    > > output is 5. Does "delete" not delete in this situation or is it no
    > > guarantee that it will print 5 or go wrong?

    >
    > > void clean( int* ptr )
    > > {
    > > delete ptr;

    >
    > > }

    >
    > > //...

    >
    > > int* ptr = new int( 5 );

    >
    > > clean( ptr );

    >
    > > cout << *ptr << endl;

    >
    > It is 'undefined behaviour', so the result may vary from one
    > implementation to another, and on different runs of the same program.
    >
    > Regards.


    Thank you. Is there a way to make a pointer undeletable when passed to
    a function?
     
    D. Susman, Mar 10, 2008
    #3
  4. D. Susman

    dizzy Guest

    D. Susman wrote:

    > Thank you. Is there a way to make a pointer undeletable when passed to
    > a function?


    Im not sure what you mean by that, but if you make it 0 (the null pointer)
    then delete won't do anything with it (will ignore).

    --
    Dizzy
     
    dizzy, Mar 10, 2008
    #4
  5. D. Susman

    D. Susman Guest

    On Mar 10, 6:59 pm, dizzy <> wrote:
    > D. Susman wrote:
    > > Thank you. Is there a way to make a pointer undeletable when passed to
    > > a function?

    >
    > Im not sure what you mean by that, but if you make it 0 (the null pointer)
    > then delete won't do anything with it (will ignore).
    >
    > --
    > Dizzy


    No, I mean that: when I pass "ptr" to "clean" -in some particular way-
    the compiler complains that data is intended to be deleted. Is there
    such a way?

    void clean( int* ptr )
    {
    delete ptr;
    }
     
    D. Susman, Mar 10, 2008
    #5
  6. D. Susman wrote:
    > On Mar 10, 6:59 pm, dizzy <> wrote:
    >> D. Susman wrote:
    >>> Thank you. Is there a way to make a pointer undeletable when passed
    >>> to a function?

    >>
    >> Im not sure what you mean by that, but if you make it 0 (the null
    >> pointer) then delete won't do anything with it (will ignore).
    >>
    >> --
    >> Dizzy

    >
    > No, I mean that: when I pass "ptr" to "clean" -in some particular way-
    > the compiler complains that data is intended to be deleted. Is there
    > such a way?
    >
    > void clean( int* ptr )
    > {
    > delete ptr;
    > }


    No. Don't pass a pointer. And don't hold onto a deleted pointer.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Mar 10, 2008
    #6
  7. D. Susman

    ppi Guest

    > No, I mean that: when I pass "ptr" to "clean" -in some particular way-
    > the compiler complains that data is intended to be deleted. Is there
    > such a way?


    As said by V.Bazarov, no, not for native types i.e. int, char etc.

    Of course you can still do it for struct/class by setting the
    destructor to private/protected.

    One example: http://blogs.msdn.com/larryosterman/archive/2005/07/01/434684.aspx

    Cheers,
    -- Paulo
     
    ppi, Mar 10, 2008
    #7
  8. D. Susman

    Lance Diduck Guest

    On Mar 10, 12:27 pm, "D. Susman" <> wrote:
    > On Mar 10, 6:20 pm, wrote:
    >
    >
    >
    >
    >
    > > On Mar 10, 5:11 pm, "D. Susman" <> wrote:

    >
    > > > Hi,

    >
    > > > When I call "clean" as shown below, shouldn't I be getting
    > > > segmentation fault due to garbage data? I am compiling with CC and the
    > > > output is 5. Does "delete" not delete in this situation or is it no
    > > > guarantee that it will print 5 or go wrong?

    >
    > > > void clean( int* ptr )
    > > > {
    > > >     delete ptr;

    >
    > > > }

    >
    > > > //...

    >
    > > > int* ptr = new int( 5 );

    >
    > > > clean( ptr );

    >
    > > > cout << *ptr << endl;

    >
    > > It is 'undefined behaviour', so the result may vary from one
    > > implementation to another, and on different runs of the same program.

    >
    > > Regards.

    >
    > Thank you. Is there a way to make a pointer undeletable when passed to
    > a function?- Hide quoted text -
    >

    There are a number of ways. This is what I do:
    void clean( int& ptr )
    {
    // delete ptr; //wont compile
    ptr=0;
    }


    std::auto_ptr<int> ptr(new int(5));
    clean(*ptr);
    cout<<*ptr<<endl;

    prints '0' always

    Lance
     
    Lance Diduck, Mar 10, 2008
    #8
  9. D. Susman

    James Kanze Guest

    On Mar 10, 8:40 pm, Lance Diduck <> wrote:
    > On Mar 10, 12:27 pm, "D. Susman" <> wrote:
    > > On Mar 10, 6:20 pm, wrote:
    > > > On Mar 10, 5:11 pm, "D. Susman" <> wrote:


    > > > > When I call "clean" as shown below, shouldn't I be
    > > > > getting segmentation fault due to garbage data? I am
    > > > > compiling with CC and the output is 5. Does "delete" not
    > > > > delete in this situation or is it no guarantee that it
    > > > > will print 5 or go wrong?


    > > > > void clean( int* ptr )
    > > > > {
    > > > > delete ptr;
    > > > > }


    > > > > //...


    > > > > int* ptr = new int( 5 );


    > > > > clean( ptr );


    > > > > cout << *ptr << endl;


    > > > It is 'undefined behaviour', so the result may vary from
    > > > one implementation to another, and on different runs of
    > > > the same program.


    > > Thank you. Is there a way to make a pointer undeletable when
    > > passed to a function?- Hide quoted text -


    > There are a number of ways. This is what I do:
    > void clean( int& ptr )
    > {
    > // delete ptr; //wont compile


    But "delete &ptr" will.

    > ptr=0;
    > }


    > std::auto_ptr<int> ptr(new int(5));
    > clean(*ptr);
    > cout<<*ptr<<endl;


    > prints '0' always


    In the end, a function must fulfill a defined contract. If you
    don't know what the contract is, you don't use the function. If
    the function's contract says it deletes the memory, you only
    pass it pointers to stuff you want deleted. And if the
    function's contract doesn't say that it deletes the memory, then
    it had better not delete it, since you're quite likely to pass
    it the address of a local variable, or whatever.

    There are only a very limited number of contractual constraints
    that can be expressed in the language. As a programmer, you
    need to respect all of the contractual constraints, not just
    those expressed in the language.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Mar 11, 2008
    #9
  10. D. Susman

    Lance Diduck Guest

    On Mar 11, 6:01 am, James Kanze <> wrote:
    > In the end, a function must fulfill a defined contract. If you
    > don't know what the contract is, you don't use the function. If
    > the function's contract says it deletes the memory, you only
    > pass it pointers to stuff you want deleted.
    > [snip]
    > There are only a very limited number of contractual constraints
    > that can be expressed in the language.

    I couldn't agree more. I have seen many people confuse themselves over
    the relation between syntax and correctness, esp over '=' and '=='. It
    seems that because the algebra textbook and C++ syntax uses these same
    glyphs, then they MUST both represent some Platonic notion of
    "sameness." Of course there is a correlation, mostly because the early
    programming languages were just trying to solve equations, and the
    syntax carried on to this day. But that is where the similarity ends.
    That said, syntax combined with simple rules goes a long way. A good
    rule is to never call delete in the first place. This simple rule
    squashes quite a few bugs. Couple that with "don't ever take the
    address of an object" and you are well on your way to never having to
    worry about memory errors.
    But you are right, that there is far more to program correctness that
    can be expressed in the language itself.
    Lance
     
    Lance Diduck, Mar 11, 2008
    #10
  11. D. Susman

    James Kanze Guest

    On 11 mar, 16:47, Lance Diduck <> wrote:
    > On Mar 11, 6:01 am, James Kanze <> wrote:


    [...]
    > That said, syntax combined with simple rules goes a long way.
    > A good rule is to never call delete in the first place. This
    > simple rule squashes quite a few bugs. Couple that with "don't
    > ever take the address of an object" and you are well on your
    > way to never having to worry about memory errors.


    That's an interesting idea. It probably goes a bit further that
    even I'd like, but...

    -- use a garbage collector,
    -- forbid dynamic allocation of objects with non-trivial
    destructors, and
    -- forbid taking the address of an existing object (so that all
    pointers are to dynamically allocated objects).

    The resulting program achieves true type safety. (I'm not sure
    how you'd handle entity objects in it, though. And maybe I'm
    just used to it, but I can't quite imagine never taking the
    address of a local object, either, though one has to admit that
    it is fraught with danger.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Mar 11, 2008
    #11
  12. D. Susman

    Andre Kostur Guest

    "D. Susman" <> wrote in
    news::

    > On Mar 10, 6:59 pm, dizzy <> wrote:
    >> D. Susman wrote:
    >> > Thank you. Is there a way to make a pointer undeletable when passed
    >> > to a function?

    >>
    >> Im not sure what you mean by that, but if you make it 0 (the null
    >> pointer) then delete won't do anything with it (will ignore).
    >>
    >> --
    >> Dizzy

    >
    > No, I mean that: when I pass "ptr" to "clean" -in some particular way-
    > the compiler complains that data is intended to be deleted. Is there
    > such a way?
    >
    > void clean( int* ptr )
    > {
    > delete ptr;
    > }
    >


    (I assume you meant "... data is intended to not be deleted...")

    Pass the object by reference. If the callee then attempts to delete the
    object by taking its address, the callee deserves what they get.

    Pass the pointer through some wrapper class (std::auto_ptr perhaps)? Same
    as above.. if the callee still extracts the pointer and tries to delete it,
    the callee deserves what they get.

    If you meant "intended to be deleted", then declare the parameter as an
    auto_ptr by value.
     
    Andre Kostur, Mar 11, 2008
    #12
    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. Horace Nunley

    why why why does function not work

    Horace Nunley, Sep 27, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    470
    =?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=
    Sep 27, 2006
  2. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    922
    Mark Rae
    Dec 21, 2006
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,074
    Smokey Grindel
    Dec 2, 2006
  4. PerlFAQ Server
    Replies:
    0
    Views:
    599
    PerlFAQ Server
    Feb 11, 2011
  5. PerlFAQ Server
    Replies:
    0
    Views:
    594
    PerlFAQ Server
    Mar 9, 2011
Loading...

Share This Page