-nogc

[Leandro Lucarella]

Brad Roberts, el 23 de abril a las 10:39 me escribiste:
> Leandro Lucarella wrote:
> 
> > Now in Tango/Druntime you already can use a dummy GC that all it does is
> > calling C malloc/free for gc_malloc/gc_free, exactly for this purpose, so
> > what -nogc should do in that case is just link against the "stub" GC
> > instead to the "basic".
> 
> This claim really needs to stop.  You can't just swap from the normal gc
> to the stub gc an expect your app to use malloc/free and behave exactly
> as it did before.  No, it'll leak.  Free will never be called (outside
> the rare case of an explicit delete).  Normal apps expect implicit
> cleanup to be invoked by the gc which will never happen in the stub.
> That's fine in tiny apps, or apps that carefully manage their own
> memory, but then you weren't using the gc in the first place for those apps.

Maybe it wasn't clear enough (and it's less clear even in you mail where
you remove all context of my response) but what I said was in response to
bearophile mail, which said (and I quote it again):

	One simple possible solution: -nogc is to write C-like programs,
	with no automatic reference counting. It doesn't include the GC in
	the final executable (making it much smaller) and in such programs
	AAs and array concatenation and closures are forbidden
	(compilation error if you try to use them). "New" allocates using
	the C heap, and you have to use "delete" manually for each of
	them.

So, no, I'm not implying that one can use the "stub" GC implementation and
just go and be happy and play with dynamic arrays and hashes and expect
that memory get freed magically.

Please read the message in its context before putting words in my mouth.

Thanks.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------