Eliminate class allocators and deallocators?

[Andrei Alexandrescu]

dsimcha wrote:
> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> 2.  Maintaining two separate heaps (the manually memory managed C heap and the
> GC'd D heap) is a massive and completely unacceptable kludge because:

Coding in a way that requires the GC to offer manual deletion is a 
completely unacceptable kludge. Most GCs could NOT offer a primitive to 
manually release memory. Designing D around a requirement that manual 
deletions work on the GC is crippling pressure on GC designers.

> 1.  If you just want to delete a few objects to make the GC run less often, you
> can just add delete statements for the common code paths, or paths where the end
> of an object's lifetime is obvious.  You then just let the GC handle the less
> common code paths or cases where object lifetimes are non-trivial and gain tons of
> simplicity for only a small performance loss.  If you have to handle all the odd
> code paths manually too, this is when bugs really start to seep in.

Many people's famous last void were "the end of an object's lifetime is 
obvious".

> 2.  Heaps have overhead.  Two heaps have twice the overhead.

Where did that come from?

> 3.  addroot(), etc. is a PITA *and* adds yet another place where you have to lock
> on the GC mutex.  Half the need for manual memory management in D is because the
> GC sometimes scales poorly to large numbers of threads.  This would definitely not
> help the situation.

So right now do you have it for free? I don't understand. What are you 
comparing against what?

> 4.  Using the C heap whenever you want the ability to manually free something
> doesn't play nicely w/ builtin language features such as classes, arrays,
> associative arrays, etc., or objects returned from library functions.

It shouldn't too.

> Because of these 4 issues, I feel that only being allowed to do manual memory
> management if you use the C heap is such an unacceptably bad kludge that it is for
> many practical purposes akin to not being allowed to do manual memory management
> at all.  This is unacceptable in a systems/performance language.

I completely disagree. I believe that "unifying" safe and unsafe styles 
under the same umbrella is an unacceptably bad kludge that is for many 
practical purposes akin to not being allowed to provide the slightest 
guarantee about any piece of D code. That's not where D should be going.

> Remember, performance/systems languages can't place excessive emphasis on safety
> and absolutely MUST assume the programmer knows what he/she is doing.  If you want
> Java, you know where to find it.

We agree on D being able to provide every bit of performance control 
needed. But my understanding you foster a programming style that's a 
hodge-podge of safe and unsafe coding under the same syntactic pretense. 
I don't think that's a good way to go.


Andrei