The problem with the D GC

[%u]

== Quote from Kyle Furlong (kylefurlong at gmail.com)'s article
> %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.

It's not ignorant from my viewpoint. You're assuming I care about the features you
described.