How to avoid?

Discussion in 'C++' started by doublemaster007@gmail.com, Jul 19, 2008.

  1. Guest

    class A;

    A *a = new A;

    A *b, *c;

    b= a;
    c= b;

    delete a;
    delete b;
    delete c;


    This is dangrous..can any one give the solution to avoid multipl
    delete??

    1) Make it NULL after delete
    2) Any other solution??????
    , Jul 19, 2008
    #1
    1. Advertising

  2. Ian Collins Guest

    wrote:
    > class A;
    >
    > A *a = new A;
    >
    > A *b, *c;
    >
    > b= a;
    > c= b;
    >
    > delete a;
    > delete b;
    > delete c;
    >
    >
    > This is dangrous..can any one give the solution to avoid multipl
    > delete??
    >
    > 1) Make it NULL after delete
    > 2) Any other solution??????


    Attention to detail.

    --
    Ian Collins.
    Ian Collins, Jul 19, 2008
    #2
    1. Advertising

  3. Smart pointers are not always an ideal solution in the real world.
    First of all, they are expensive in real-time/mission-critical
    systems. Additionally, they cannot be easily introduced into legacy
    systems-- one example is the company where I work. The original
    platform was developed at least 15 years ago, in C. And overtime, it
    has been significantly ported to C++ ( These days, we mostly add
    features, and maintain the product). I work with pointers on daily
    basis. And not being stupid and clumsy with pointers is included in
    job description.

    Lastly, the new generation boost and RT1 smart pointers are too new
    to be 100% relied on. I would recommend using them unless management
    and fully aware of ramifications and implications.


    As for your problem domain, if a smart pointer is in fact permissible,
    choose one one of the following (or roll your own):

    std::auto_ptr<>
    std::tr1::shared_ptr<>
    std::tr1::weak_ptr<>
    boost::intrusive_ptr<>
    boost::scoped_ptr<>
    boost::scoped_array<>, boost::shared_array<>
    std::unique_ptr<>


    PuzzleCracker
    puzzlecracker, Jul 20, 2008
    #3
  4. dean Guest

    Smart pointers may protect you from system crash, but the first thing
    should be checking the whole logic flow.
    dean, Jul 20, 2008
    #4
  5. Jim Langston Guest

    <> wrote in message
    news:...
    > class A;
    >
    > A *a = new A;


    a is what newed A. So it "owns" the instance.

    > A *b, *c;
    >
    > b= a;
    > c= b;


    b and c did not new A. They do not own it, so should not delete it.

    > delete a;


    Fine. a "owns" the instance.

    > delete b;
    > delete c;


    Wrong. b and c do not "own" the instance so should not delete anything.

    > This is dangrous..can any one give the solution to avoid multipl
    > delete??
    >
    > 1) Make it NULL after delete
    > 2) Any other solution??????


    It's the same as this.

    const char MyString = "Hello World":
    char* CharP = MyString;

    delete CharP;

    You would never do that, right? Why delete CharP if you did not new it?
    Same thing, pay attention to what you're doing.
    Jim Langston, Jul 20, 2008
    #5
  6. Guest

    On Jul 19, 10:46 pm, "Jim Langston" <> wrote:
    > <> wrote in message
    >
    > news:...
    >
    > > class A;

    >
    > > A *a = new A;

    >
    > a is what newed A.  So it "owns" the instance.
    >
    > > A *b, *c;

    >
    > > b= a;
    > > c= b;

    >
    > b and c did not new A.  They do not own it, so should not delete it.
    >
    > > delete a;

    >
    > Fine.  a "owns" the instance.
    >
    > > delete b;
    > > delete c;

    >
    > Wrong.  b and c do not "own" the instance so should not delete anything..
    >
    > > This is dangrous..can any one give the solution to avoid multipl
    > > delete??

    >
    > > 1) Make it NULL after delete
    > > 2) Any other solution??????

    >
    > It's the same as this.
    >
    > const char MyString = "Hello World":
    > char* CharP = MyString;
    >
    > delete CharP;
    >
    > You would never do that, right?  Why delete CharP if you did not new it?
    > Same thing, pay attention to what you're doing.

    Thank you, I knew removing two deletes wer one solution..i just wanted
    to is there an way from the compiler to get help regarding these
    mistakes

    so these are the possible solutions

    1) Null after delete and check for null b4 delete
    2) Smart pointers but it may be expensive!

    Any other solution?? is there any design pattern to avoid this?
    , Jul 20, 2008
    #6
  7. James Kanze Guest

    On Jul 20, 9:40 am, ""
    <> wrote:
    > On Jul 19, 10:46 pm, "Jim Langston" <> wrote:


    > > <> wrote in message


    > >news:....


    > > > class A;


    > > > A *a = new A;


    > > a is what newed A. So it "owns" the instance.


    > > > A *b, *c;


    > > > b= a;
    > > > c= b;


    > > b and c did not new A. They do not own it, so should not delete it.


    > > > delete a;


    > > Fine. a "owns" the instance.


    > > > delete b;
    > > > delete c;


    > > Wrong. b and c do not "own" the instance so should not
    > > delete anything.


    That's one idiom. Not the only one.

    > > > This is dangrous..can any one give the solution to avoid multipl
    > > > delete??


    > > > 1) Make it NULL after delete
    > > > 2) Any other solution??????


    > > It's the same as this.


    > > const char MyString = "Hello World":
    > > char* CharP = MyString;


    > > delete CharP;


    > > You would never do that, right? Why delete CharP if you did
    > > not new it? Same thing, pay attention to what you're doing.


    > Thank you, I knew removing two deletes wer one solution..i
    > just wanted to is there an way from the compiler to get help
    > regarding these mistakes


    You could use a garbage collector. Not that that will solve all
    your problems.

    > so these are the possible solutions


    > 1) Null after delete and check for null b4 delete


    That's not usually a solution.

    > 2) Smart pointers but it may be expensive!


    Or it may not be. There is no universal solution. Smart
    pointers can help in some specific cases, however.

    > Any other solution?? is there any design pattern to avoid this?


    More than a design pattern, just design: defining the lifetime
    of your objects at the design level.

    Other than that, I'd suggest avoiding dynamically allocated
    objects whenever possible.

    --
    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, Jul 20, 2008
    #7
  8. Guest

    On Jul 20, 3:40 am, ""
    <> wrote:
    > On Jul 19, 10:46 pm, "Jim Langston" <> wrote:
    >
    > > <> wrote in message

    >
    > >news:...

    >
    > > > class A;

    >
    > > > A *a = new A;

    >
    > > a is what newed A. So it "owns" the instance.

    >
    > > > A *b, *c;

    >
    > > > b= a;
    > > > c= b;

    >
    > > b and c did not new A. They do not own it, so should not delete it.

    >
    > > > delete a;

    >
    > > Fine. a "owns" the instance.

    >
    > > > delete b;
    > > > delete c;

    >
    > > Wrong. b and c do not "own" the instance so should not delete anything.

    >
    > > > This is dangrous..can any one give the solution to avoid multipl
    > > > delete??

    >
    > > > 1) Make it NULL after delete
    > > > 2) Any other solution??????

    >
    > > It's the same as this.

    >
    > > const char MyString = "Hello World":
    > > char* CharP = MyString;

    >
    > > delete CharP;

    >
    > > You would never do that, right? Why delete CharP if you did not new it?
    > > Same thing, pay attention to what you're doing.

    >
    > Thank you, I knew removing two deletes wer one solution..i just wanted
    > to is there an way from the compiler to get help regarding these
    > mistakes
    >
    > so these are the possible solutions
    >



    > 1) Null after delete and check for null b4 delete


    delete null pointer is valid and does nothing so no need to check.


    > 2) Smart pointers but it may be expensive!
    >
    > Any other solution?? is there any design pattern to avoid this?
    , Jul 20, 2008
    #8
  9. Jim Langston Guest

    <> wrote in message
    news:...
    > On Jul 20, 3:40 am, ""
    > <> wrote:
    >> On Jul 19, 10:46 pm, "Jim Langston" <> wrote:
    >>
    >> > <> wrote in message

    >>
    >> >news:...


    [Sniipping a bit]

    >> > > class A;

    >>
    >> > > A *a = new A;

    >>
    >> > > A *b, *c;

    >>
    >> > > b= a;
    >> > > c= b;

    >>
    >> > > delete a;
    >> > > delete b;
    >> > > delete c;


    >> 1) Null after delete and check for null b4 delete

    >
    > delete null pointer is valid and does nothing so no need to check.


    Wrong in this case. Consider from the original code.

    A *a = new A;
    A *b, *c;
    b = a;
    c = b;

    delete a;
    a = NULL;
    // At this point what are b and c? NULL? Nope. They still point to the
    original address which has already been deleted. Setting a variable to NULL
    only works for that variable, not for anything else that pointed to the same
    memory address. True, delete a; will not crash, but delete b; and delete c;
    will still crash. In this program setting the varaible to NULL after
    deleting does nothing useful.
    Jim Langston, Jul 21, 2008
    #9
  10. James Kanze Guest

    On Jul 30, 11:58 am, blargg <> wrote:
    > In article <6MSgk.3157$>,
    > "Jim Langston" <> wrote:


    > > A *a = new A;
    > > A *b, *c;
    > > b = a;
    > > c = b;


    > > delete a;
    > > a = NULL;
    > > // At this point what are b and c? NULL? Nope.
    > > // They still point to the original address which
    > > // has already been deleted.


    > (sorry, a little late of a reply) Actually, b and c have
    > indeterminate contents after delete a. Doing ANYTHING with
    > them is undefined, other than assigning a new value. See
    > 3.7.3.2 in the C++03 standard. Even doing "if ( b != NULL )"
    > is undefined.


    There are a couple of problems with that statement. The first
    is that as far as I know, I don't think it has ever really been
    decided whether the contents (the actual bits) are
    indeterminate. The *value* is indeterminate, and you can't
    access the pointer as a pointer, but what about something like:

    A *a = new A ;
    A *b ;
    memcpy( &b, &a, sizeof( A* ) ) ;
    delete a ;
    if ( memcmp( &a, &b, sizeof( A* ) ) == 0 {
    // ...
    }

    The memcmp is certainly defined behavior; I don't think it has
    ever been fully decreed whether the result of that final memcmp
    is guaranteed to be 0.

    And there are other things but assigning a new value which are
    allowed: taking the address or passing by reference, for
    example, or accessing the underlying raw bytes.

    --
    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, Jul 30, 2008
    #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. Max

    avoid the warnig

    Max, Sep 18, 2003, in forum: VHDL
    Replies:
    6
    Views:
    771
    Jim Lewis
    Sep 19, 2003
  2. avoid latches

    , Aug 7, 2005, in forum: VHDL
    Replies:
    2
    Views:
    1,889
    Hubble
    Aug 8, 2005
  3. Konrad

    how to avoid authentication

    Konrad, Jun 25, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    917
    Bassel Tabbara [MSFT]
    Jun 26, 2003
  4. Alexander Malkis
    Replies:
    8
    Views:
    521
    Alexander Malkis
    Apr 14, 2004
  5. Roger23
    Replies:
    2
    Views:
    998
    Roger23
    Oct 12, 2006
Loading...

Share This Page