manual memory management

[Mehrdad]

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



Yup.


Also might mention, we implemented a compiler for a subdialect of 
Python (including full closures) for our compilers course, which 
the compiler subsequently translated to C++.

GC wasn't required (we were allowed to never deallocate), but 
since I didn't feel like doing that I added reference counting 
using a lot of shared_ptr's and intrusive_ptr's.

I also added a GC just for the sake of catching cyclic 
references, but it was just that -- everything was reference 
counted, so if you never had cyclic references, the GC _never_ 
kicked in, period.


(True, it wouldn't give you the power of a systems language, but 
that's quite obviouly not my point -- the point is that it's a 
_perfectly possible_ memory-safe language which we made, so I 
don't understand Walter's comment about a GC being "required" for 
a memory-safe language.)