manual memory management

[Mehrdad]

On Wednesday, 9 January 2013 at 09:30:41 UTC, deadalnix wrote:
> 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.



"The _leak_ is not GC'd"?



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


Re-read what he wrote, you completely missed what we're saying.