How does D improve design practices over C++?

[Janderson]

Tony wrote:
> "Janderson" <ask at me.com> wrote in message 
>> Also #defines really arn't a problem for cpu at compile time, your right 
>> there.  I'm trying to point out that using #defines for const is totally 
>> rediculus (sorry for being so harsh).  No C++ book or expert would 
>> recommend it and it doesn't result in any run-time optimisation what so 
>> ever.
> 
> Obviously I take language feature "recommendation" with a grain of salt. I 
> do #define because I've never had any problem with it (and look at the 
> Windows header files sometime!) and #defines don't create a data object in 
> memory. It's simply never been a problem. Now if one is "hell bent/anal" 
> about "doing away with the preprocessor, power to them, "it ain't me" 
> though. I don't want the template machinery taking over the capability of 
> the preprocessor: I use it to mutate the language and experiment. I will 
> probably implement a preprocessor to replace or add to what I have with C++ 
> before I jump into compiler development for my language that is evolving.

It seems you might need to think outside of the C++ box.  C++ there are 
much more powerful processors then the one that games with C++.  In many 
aspects D has a huge advantage with its pre-processing replacements.

As to the windows.  These where designed for C not C++.  Even MFC is old 
and something Microsoft has not supported for a long time.  It was 
created during the transition time from when Microsoft was switching 
from C to C++.  Look at where microsoft is going (.Net, C#, managed 
C++), what do they no-longer use?  Look at C++0x, what are they 
changing, what are they adding to reduce macro use?

I'll leave this as an excise to u because I fear if that I tell you'll 
just want to argue more.  If you find it for yourself you might be more 
inclined to be more open minded or at least present some more informed 
arguments.

-Joel