== Quote from Timon Gehr (timon.g...@gmx.ch)'s article > Andrei Alexandrescu wrote: > > I am sorry, you simply have no case - each and every argument you put > > forth has no strength or is just wrong. We could spend time on debating > > each, but I suspect that would do little toward convincing you of what > > is after all a simple fact, but one with many subtle facets. It might > > not a good use of our time to further engage in a diatribe on this. The > > delete keyword will go, as will class-specific new and delete. > > > > > > Andrei
Is it correct that the current D GC implementation puts delete'd allocations into a freelist (or bucket) to be reused when 'new' is invoked again? > Ok, lets stop. Custom allocators and delete should probably be removed from D: > Some of my facts: > * freelist is faster if most allocation and deallocation concentrates on only > one > class. (see attachment) I think this is also the reason it increases DMDs > speed. > Token and Scope are quite obvious bottlenecks.. > * such bottlenecks will most of the time only be detected when development is > almost finished. (Almost never for library code, so I don't get why STL uses > custom allocators at all.) > * premature optimization is evil (see STL custom allocators) > * late optimization: it is easy if there are custom allocators. In C++ it is > even > trivial. Nice design. Still no clue why STL is abusing it. > * that form of custom allocators does not play nicely with Ds Garbage > collector > though, because it changes the semantics of 'new', ergo builtin custom > allocators > should probably indeed be removed from D. > * this makes this form of optimization painful in D without custom allocators. > This is what I was instinctively scared about. Fact is: it is also painful > with > them, because you don't get the 'delete's for free as in C++. I was somewhat > inconsiderate on this. > * it is possible that hinting the GC is only about twice as bad (again, see > attachment). > And some notes: > * the fact that you think all my points were worthless or wrong implies that > you > either did not read all of them or have not considered them yourself when > making > your decision. I think that is scary. I find it nuts that someone considers blaming/shunning language features just to mask bad runtime semantics they refuse to fix - but maybe it's just my ignorance on the subject that professes that view.