How does D improve design practices over C++?

[Janderson]

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.

> 
>> - 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.

> 
>> - 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.


> 
>> - 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.

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.

> 
>> - Garbage collection
> 
> That's a major deal breaker for me.

Garbage collection can be turned off in D if you don't need it.  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.


> 
>> - 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.  D restricts operators making them more difficult to use for 
something they are not really designed for, ie encouraging better design.


> 
>> - 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.

> 
>> - 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.

> 
>> - 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.

> 
>> - 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.  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 
> 

I hope this has been helpful.

BTW: How do I put this lightly.  I think you'd be able to find some C++ 
experts that will disagree with a couple of the things I've said but on 
the whole this is pretty elementary stuff.

-Joel