manual memory management

[deadalnix]

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/