C++, D: Dinosaurs?

[Tony]

"Walter Bright" <newshound1 at digitalmars.com> wrote in message 
news:gf5r4l$2kt9$1 at digitalmars.com...
> Tony wrote:
>> Please clarify for me the mem mgmt of D: is the garbage collector 
>> optional or not? Just allowing me to replace "getmorecore()" or something 
>> like that and then having the collector on top of that is unacceptable to 
>> me. I think you may be saying that dynamic memory is in every program, 
>> which again is not acceptable to me.
>
> You can pretty much avoid all gc in D by doing your allocations using 
> malloc/free and overloading operators new and delete for your classes. 
> Some language features rely on gc, like dynamic closures, array 
> concatenation, and the built-in associative arrays, but those features 
> need not be used.
>
>
>> Really, memory control is a key issue when choosing a language for me 
>> anyway. I require that level of closeness to the hardware. Anything less 
>> is too 4GL-like for me.
>
> I understand how you feel. For a very long time, I felt the same way. I 
> wanted the control. I thought GC was for below average programmers who 
> couldn't handle memory allocation. I worked with a Java implementation for 
> a while when Java first came out (building a native Java compiler) and 
> came to realize the basis of my beliefs were unfounded.
>
> GC has some compelling advantages:

To you and a bunch of others it does, you mean. "Compelling", to me, means 
something like "leapfrogs enough other issues or capabilities and/or in a 
nicer way" than what is currently available or what can be created.

>
> 1. GC programs can be faster
>
> 2. GC programs can use less memory
>
> 3. GC programs can be guaranteed to be memory safe
>
> 4. GC programs are faster to develop and have fewer bugs

None of which "sell me" on GC. But please don't "go there"! (I know that "to 
GC or not to GC" is a flamewar topic). Who knows, maybe my own memory 
management architecture (the reworked (new and improved! literally) version 
not yet in production, but soon) will evolve to be the backend to a garbage 
collector. As an independent developer, I have to keep my cards close to my 
chest about some of (one?) the reasons why I thing "my way" is compelling 
(in the true sense of the word). Gar bage collectors have a (some?) 
characteristic(s) that may indeed be deal breakers for some (a lot?) of 
software. That's why I think GC should be an opt-in rather than an opt-out 
choice. That's a key characteristic of C++: opt-in. And I really, really 
like that level of creative freedom. (Of course, in my own language, I'll do 
that even better than C++ does. :) Which is not to say though that I expect 
to replace C++. My language will be "higher level" (whatever that means) 
than C++).

Tony