On Wednesday, 9 January 2013 at 07:33:24 UTC, Rob T wrote:
On Wednesday, 9 January 2013 at 07:23:57 UTC, Mehrdad wrote:
On Wednesday, 9 January 2013 at 07:22:51 UTC, deadalnix wrote:
Well, you CAN indeed, create a dumbed down language that is
memory safe and don't require a GC.
Yeah, that's 1 of my 2 points.
The other one you still ignored: the GC doesn't bring much to
the table. (Re C# Java etc.)
There is a point being made here that is perfectly valid. There
is a form of memory leak that a GC can never catch, such as
when when memory is allocated and simply never deallocated by
mistake due to a persistent "in use" pointer that should have
been nulled but wasn't.
As long as you have the pointer around, the memory leak is not
GC's.
In addition, the GC itself may fail to deallocated freed memory
or even free live memory by mistake. I've seen bugs described
to that effect. There simply is no panacea to the memory leak
problem. What a GC does do, is free the programmer from a ton
of tedium, and even allow for constructs that would normally
not be practical to implement, but it can never guarantee
anything more than that.
False pointer are mostly solved by using 64bits pointers. See :
http://www.deadalnix.me/2012/03/05/impact-of-64bits-vs-32bits-when-using-non-precise-gc/
