The "no gc" crowd

[Manu]

On 10 October 2013 01:40, Johannes Pfau <nospam at example.com> wrote:

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

Exceptions have a pretty well defined lifetime... can't they be manually
cleaned up by the exception handler after the catching scope exits?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131010/5fba7116/attachment-0001.html>