How does D improve design practices over C++?

[Tony]

"Janderson" <ask at me.com> wrote in message 
news:gepsn2$21jr$1 at digitalmars.com...
> Tony wrote:
>> Let me be facetious with Janderson's list plz...
>>
>> "Janderson" <ask at me.com> wrote in message 
>> news:ge8tpd$1f6b$1 at digitalmars.com...
>>> Hi,
>>>
>>> I was talking with some collages at work and they asked me how D 
>>> enforces good programming practices.   For course I mentioned a couple 
>>> of the ones I knew of hand -
>>>
>>> - Unit checking
>>
>> Not sure what is meant by this, but it sounds minor.
>
> Sure C++ can do unit checking, but its not built in.  You have to use 
> macros or templates in something that is not really designed to work 
> correctly with the language.  Even if you ignore that there's a barrior to 
> entry by not having something like this in the language.  By having it in 
> the language good coding practices are encouraged.

I write unit tests. I don't know why I'd need or want language support for 
that.

>
>>
>>> - Design by contract
>>
>> Overblown concept, but can be done with C++ also to a more than adequate 
>> degree (heard of assertions?).
>
> Yes this can be done with C++ but D takes it it many steps further.

Like I said, I find the techniques more important that some implementation 
of them (mechanism rather than policy?).

>
>>
>>> - Invariant checks
>>
>> Part of DbC concepts. See Koenig and Moo's array example in "Accelerated 
>> C++". Which, btw, leads me to believe that there are few instances "where 
>> the stars line up just right" for invariant checking to be useful.
>
> Invariant checks can be done in C++ but its very unweildly.  It is very 
> annoying to have to instruct each function with scope guards.  D 
> encourages good invariant checking by making it easy.

But again, I am thinking that the scenarios where invariants can be 
established is a very small subset of classes.

>
>
>>
>>> - Stronger const
>>
>> Insignificant. I still use many #defines just because I know that const 
>> vars take space and #defines are a pre-compile-time thing (yes, I value 
>> the preprocessor for some uses, this being one of them).
>
> Actually any good compiler will inline const variables but I'm not talking 
> about those sort of const.  Also you pay 2 costs for using #define:
>
> 1) its not typesafe
> 2) it adds to your compile time because the pre-processor has to do more.

Coming from the Windows world, one isn't "afraid" of 1 above whatsoever. 
Compile time? CPUs are evolving faster than I'll ever be able to outpace 
them with the complexity or volume of my software.

>
> I'm talking about the const you put in function declarations which are 
> very important.
>
>
>>
>>> - Modules
>>
>> If that means doing away with header files, I don't think I like it. I 
>> rely on headers as the engineer's blueprint (of course you have to write 
>> very clean code to have that make sense).
>
> I think this means you simply haven't run up against any of the problems 
> with header files.

That's probably exactly what it means. But maybe I'm tooling up to write 
utility software rather than large scale software.

>
>>
>>> - Garbage collection
>>
>> That's a major deal breaker for me.
>
> Garbage collection can be turned off in D if you don't need it.

So I've been told. But I think the default should be to include it when you 
like rather than the other way around. Obviously, I can use a GC library in 
C++ if I was so inclined.

> However for me (even when performance is very important and a game 
> programmer) I can deal with it.
>
>>
>>> - No automatic copy constructor
>>
>> Can't comment.
>
> I'd encourage you to read "See C++ Coding Standards: 101 Rules, 
> Guidelines, and Best Practices (C++ In-Depth Series)" by Herb Sutter, 
> Andrei Alexandrescu
> http://www.amazon.com/Coding-Standards-Guidelines-Practices-Depth/dp/0321113586
> one of the only books that has Bjarne Stroustrups seal of approval.

> Effective C++ is another good read.

Been there a number of times. Automatic copy constructor issue didn't catch 
my eye though obviously.

>
>
>>
>>> - More restrictive operators
>>
>> I'm not really concerned about that. I'd avoid them unless doing 
>> numerical programming.
>
> The point here is that in C++ operators where used for all sorts of things 
> that they where not designed for.  This makes code hard to follow.

I whole heartedly agree!

> D restricts operators making them more difficult to use for something they 
> are not really designed for, ie encouraging better design.

Minor. I know when not to use operators (read: hardly ever!).

>
>
>>
>>> - Delegates (Specifically, encouraging there use by making them simple 
>>> to use)
>>
>> Can't comment.
>
> C++ form of delegates/functors are horrible to debug and use.  Even the 
> ones in Andrei Alexandrescu loki which are nicer are still not as easy to 
> use as D's.  Delegates are a powerful tool and are very useful in 
> decoupling code.  They should be encouraged by being easy to use.

Apparently I should look that one up, cuz I don't even know what they are. 
But that you said "decoupling", makes me interested.

>
>>
>>> - Specific constructs such as Interfaces
>>
>> C++ has interfaces. Should it be a keyword? Maybe. How are D's interfaces 
>> different from C++'s?
>
> C++ has interfaces which can easily become abstractions.  This is not 
> good.  By saying something is an interface, your documenting -> this is an 
> interface don't change me.  Its much better when the code can enforce 
> rules rather then by just comments.  You look at an interface in D and you 
> know its an interface, C++ you have to read though the code or hope 
> someone has documented it.  I'm not the best explainer in the world so 
> maybe someone else can explain this better.

I use naming standards for interfaces: iSomeClass, for example. I'm not sure 
what problem D's interfaces solve. I find no problem with C++'s interface 
techniques.

>
>>
>>> - More restrictive casting
>>
>> Ouch!! I prefer to slice bread with a knife rather than having a machine 
>> do it. (Bad analogy, but y'all get the point).
>
> I'd rather the machine catch something at compile time rather then 
> runtime.

As long as I'm not prevented from doing casting I know is safe, it's fine.

>
>>
>>> - No C style Macros
>>
>> Implementing a template or template system with a good preprocessor is 
>> something completely different than macros. I value the preprocessor for 
>> such uses (I wish it was more powerful than in C++ though).
>
> Macros in C++, powerful yes but I think they are over used.

Macros and using the preprocessor as a template machine are apples and 
oranges. Every use of the the C++ preprocessor does not fit the definition 
of "macro", thought everyone pounces on the obvious as you do below:

> D has a replacement for the macro system which is more powerful.  Most of 
> which is not done in the preprocess.  I've seen more horrible C++ macros 
> then I can count.  They are definably not a good practice.   Any good C++ 
> books will talk about "Macro side effects".  They arn't typesafe, there's 
> a possibility of having an operation performed in a place you don't 
> expect.  They don't work will on multilines (i hate \ because its not 
> maintainable and error prone).  Doing things like string operations are 
> just non-intuitive.
>
> The other bad thing about macros is they are extremely difficult to debug.
>
> D provides many of the functionalities of macros in a nicer form:
> - Better Templates
> - Mixins
> - Version
>
> Site note: About ~80% of macros I've seen in C++ could have been done with 
> templates in C++ and they would have been much better in so many ways.

Tony