confused with garbage collection

[rahul8143]

hello,
I read that when control moves out of function/program local
variables dies automatically. then where garbage collection comes in
picture?
Is that needed because of memory leaks in programs?
regards,
rahul.

 

[benben]

hello,

I read that when control moves out of function/program local
variables dies automatically. then where garbage collection comes in
picture?

Because local variables are not the only things that chews up memory. Think
about heap-based objects, etc.

 

[Guest]

Obviously.

Your answer may be understood as if garbage collection "is needed" for
memory leaks.

It's not needed but just one way of dealing with memory leaks.

I don't have experience with it to comment on whether it's a way that can be
used only with resources where the order of clean-up is not important. So I
won't comment

Ali

 

[John Fullman]

when you use the new keyword to create an object... it doesn't die
automatically. (because it's in the heap)
You must delete it using the delete keyword. Objects on the stack die
automatically.

*Rant on*
Some programmer are lazy and don't like dealing with deleting what they
new. And garbage collection was born.
*Rant off*

 

[benben]

*Rant on*

Some programmer are lazy and don't like dealing with deleting what they
new. And garbage collection was born.
*Rant off*

You can't blame memory leakage as programmer laziness. Memory leak is common
place in lots of systems and just by putting deletes over the places won't
completely solve the problem. Things like multiple owner ship, exceptions,
order of destruction all add to the complexity of eliminating memory leak.

I see automatic garbage collection as a way to free programmers from memory
management tasks in general, as opposed to dealing just with memory leaks.
But it is not the only workable strategy.

ben

 

[msalters]

benben schreef:

You can't blame memory leakage as programmer laziness. Memory leak is common
place in lots of systems and just by putting deletes over the places won't
completely solve the problem. Things like multiple owner ship, exceptions,
order of destruction all add to the complexity of eliminating memory leak.

No they don't. Multiple ownership: use a boost::shared_ptr (also in
TR1)
Exceptions: use any smart pointer (even std::auto_ptr). Order of
destruction:
not sure what exactly you mean, but boost::shared_ptr can solve the
order issues I'm aware of. Cyclic dependencies are still a reason for
attention then, but one can simply reset an owning shared_ptr and thus
break a cycle in a controlled fashion.

I see automatic garbage collection as a way to free programmers from memory
management tasks in general, as opposed to dealing just with memory leaks.
But it is not the only workable strategy.

Apparently, it's useful in some lambda constructs when passing
temporary
constructs around. Their types ideally are locally defined so one can't
have smart pointers to them. In all fairness, this is still esoteric
C++

HTH,
Michiel Salters