The problem with the D GC

[Kyle Furlong]

%u wrote:
> == Quote from Bill Baxter (dnewsgroup at billbaxter.com)'s article
>> Sean Kelly wrote:
>>>> This seems to be a very big issue.  The GC seems to be pretty much
>>>> useless right now if you're going to have a lot of floating point data
>>>> in your app.
>>> For what it's worth, I ran the test above with the modified GC in Tango,
>>> for 10000 iterations of the "while(1)" loop.  The default behavior
>>> roughly matched Phobos, with an 89 second run time and over 340MB of
>>> memory consumed and growing steadily.  Then I told the GC to not scan
>>> the arrays using the following calls:
>>>
>>>     gc.setAttr( data.ptr, GC.BlkAttr.NO_SCAN );
>>>     gc.setAttr( incoming.ptr, GC.BlkAttr.NO_SCAN );
>>>
>>> A test with these changes in place dropped the run time to 7 seconds
>>> with 43MB of memory consumed and not growing.
>>>
>>> I grant that this isn't quite as nice as if D just figured out whether
>>> to scan the block using TypeInfo, but at least it grants the programmer
>>> a way to customize GC behavior somewhat to tune application performance.
>>>  The only stipulation with the current implementation is that block
>>> attributes will not be preserved if an array is resized.  This isn't
>>> terribly difficult to fix, but I haven't done so yet.
>> I'd certainly be willing to do that sort of thing in my code to make the
>> problem go away in the short term.  In my case all of those setAttr
>> calls would be hidden away in library code, so it wouldn't make life any
>> harder for everyday use.
>> But it's not much use as a workaround until Tango is actually
>> downloadable somewhere.  :-)
>> Once Tango is available, though, that would certainly be better than the
>> alternative of rewriting my library to use malloc/free.  If that's going
>> to be necessary then I think I'll just as soon go back to C++ where at
>> least I can use smart pointers.  The integrated GC is the #1 reason I'm
>> using D in the first place, and if I can't realistically use that then I
>> might as well be using C++.
>> --bb
> 
> I feel the same way. Without GC, D is just C++ with a few more features.

I do not think that this is even remotely valid. Think of everything you 
arent doing in D. You arent hacking macros with the preprocessor, you 
arent declaring methods outside of classes, globally overloading 
operators... To say that D is C++ + GC + some other features is just 
plain ignorant.