The "no gc" crowd

Johannes Pfau nospam at example.com
Wed Oct 9 08:40:56 PDT 2013


Am Wed, 9 Oct 2013 10:36:36 -0400
schrieb Michel Fortin <michel.fortin at michelf.ca>:

> > 
> > @refcounted interface X{};
> > @refcounted class Y {};
> > class X1 : X;
> > class Y1 : Y;
> > 
> > Now we know for sure that all these classes and SubClasses are
> > refcounted.
> 
> The problem is that you can't cast Y to its base class Object
> (because you'd be casting an ARC pointer to a GC one and the
> reference count would not be maintained). Even calling Object's
> functions should be prohibited (because the "this" pointer is a GC
> pointer inside of Object's functions, and it could be leaked). So, de
> facto, by introducing all the necessary safety limitations, you've
> practically made Y a root class. The only things you can safely
> access from the base non-ref-counted class are its variables and its
> static functions.

I see. That's a good point why a separate object hirarchy is necessary.

> On top of that all that, if your goal is to go GC-free, you have to 
> reinvent the whole standard library (so it uses ref-counted classes) 
> and you still have to avoid the common pitfalls of implicit
> allocations (array concat for instance). So it's not terribly useful
> for someone whose goal is to avoid the GC.
> 

I don't think the standard lib is not that much of a problem, at least
there's a way to avoid it (and some modules, std.algorithm, std.digest,
std.uuid already are 99% GC free).

But if someone really wants to strip the GC _completely_ there's a huge
issue with memory management of Exceptions.


More information about the Digitalmars-d mailing list