How to avoid?

[doublemaster007]

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??????

 

[Ian Collins]

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.

 

[puzzlecracker]

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

 

[dean]

Smart pointers may protect you from system crash, but the first thing
should be checking the whole logic flow.

 

[Jim Langston]

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.

 

[doublemaster007]

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



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


Fine.  a "owns" the instance.


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



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?

 

[James Kanze]

That's one idiom. Not the only one.

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.

 

[george.priv]

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.

 

[Jim Langston]

[Sniipping a bit]

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.

 

[James Kanze]

(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.