Smart pointers instead of GC?
    Araq 
    rumpf_a at web.de
       
    Tue Feb  4 05:03:23 PST 2014
    
    
  
>
> I've seen you say more than once that you can't bond with the 
> GC, and believe me I understand, if you search back through the 
> forums, you'll find one of the first things I did when I got 
> here was complain about the GC. But what you're saying is "I 
> can't bond with this horrible GC so we need to throw it out and 
> rebuild the compiler to support ARC." All I am saying is "I 
> can't bond with the horrible GC, so why don't we make a better 
> one, that doesn't ruin responsiveness, because I've seen it 
> done in other places and there is no technical reason D can't 
> do the same, or better."
There are lots of technical reasons why D's GC is just the way it 
is and why Java and C# can do better. They have been enumerated 
in this forum a lot of times, you simply chose to ignore them:
1. D doesn't restrict pointers, interior pointers abound 
especially thanks to the design of slices. Interior pointers are 
a problem for every high performance GC algorithm I'm aware of.
2. D's design doesn't easily allow for read or write barriers in 
general. You simply cannot make a GC behave without barriers.
3. Unions cause some (minor) problems.
In general the type system doesn't distinguish between GC'ed 
memory and manually managed memory at all.
> Now that I've started to read the GC Handbook I am starting to 
> suspect that using D, there might be a way to create a 
> completely pause-less GC. Don't hold me too it, I don't know 
> enough yet, but D has some unique capabilities that might just 
> make it possible.
That's just bullshit. The opposite is true: Of the big players D 
is easily the language that is most hostile to an efficient GC 
implementation.
    
    
More information about the Digitalmars-d
mailing list