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