<div dir="ltr">On 10 October 2013 01:40, Johannes Pfau <span dir="ltr"><<a href="mailto:nospam@example.com" target="_blank">nospam@example.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Am Wed, 9 Oct 2013 10:36:36 -0400<br>
schrieb Michel Fortin <<a href="mailto:michel.fortin@michelf.ca">michel.fortin@michelf.ca</a>>:<br>
<br>
> ><br>
<div class="im">> > @refcounted interface X{};<br>
> > @refcounted class Y {};<br>
> > class X1 : X;<br>
> > class Y1 : Y;<br>
> ><br>
> > Now we know for sure that all these classes and SubClasses are<br>
> > refcounted.<br>
><br>
> The problem is that you can't cast Y to its base class Object<br>
> (because you'd be casting an ARC pointer to a GC one and the<br>
> reference count would not be maintained). Even calling Object's<br>
> functions should be prohibited (because the "this" pointer is a GC<br>
> pointer inside of Object's functions, and it could be leaked). So, de<br>
> facto, by introducing all the necessary safety limitations, you've<br>
> practically made Y a root class. The only things you can safely<br>
> access from the base non-ref-counted class are its variables and its<br>
> static functions.<br>
<br>
</div>I see. That's a good point why a separate object hirarchy is necessary.<br>
<div class="im"><br>
> On top of that all that, if your goal is to go GC-free, you have to<br>
> reinvent the whole standard library (so it uses ref-counted classes)<br>
> and you still have to avoid the common pitfalls of implicit<br>
> allocations (array concat for instance). So it's not terribly useful<br>
> for someone whose goal is to avoid the GC.<br>
><br>
<br>
</div>I don't think the standard lib is not that much of a problem, at least<br>
there's a way to avoid it (and some modules, std.algorithm, std.digest,<br>
std.uuid already are 99% GC free).<br>
<br>
But if someone really wants to strip the GC _completely_ there's a huge<br>
issue with memory management of Exceptions.<br>
</blockquote></div><br></div><div class="gmail_extra">Exceptions have a pretty well defined lifetime... can't they be manually cleaned up by the exception handler after the catching scope exits?</div></div>