-nogc

[Sean Kelly]

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> Brad Roberts wrote:
> > 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.
> Totally agreed. I've always wondered what the purpose of the stub GC was
> in druntime. "We can implement an appallingly crappy allocation model"
> is the only message I'm getting.

It was originally intended as a demo for how to plug a new GC into the lib
when I wrote it for Tango.  I left it in place mostly because the DLL demo
for Win32 actually links this "stub" implementation, and it seemed preferable
to have something that would actually allocate memory than segfault if
the DLL startup code did things in a bad order.  A few people have wanted
to try and write a small footprint C-like app in D as well, so it's a handy if
not terribly user-friendly option for that sort of thing.  The few times I've
brought this up in the past, I've always been careful to say that array and
AA operations will leak if linked against this lib.