How does D improve design practices over C++?

[Denis Koroskin]

On Tue, 04 Nov 2008 07:13:24 +0300, Tony <tonytech08 at gmail.com> 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.
>

It is a recommended practice to supply tests with your source code. These  
tests are put into special section and run with upon startup (activated by  
a compiler switch). In D, code is not considered reliable unless it has a  
comprehensive set of tests.

>> - Design by contract
>
> Overblown concept, but can be done with C++ also to a more than adequate
> degree (heard of assertions?).
>

No, it isn't.

Asserts are here too (at a lanugage level) and this is another plus:

int foo() {
     if (condition) {
         return 42;
     }

     assert(false); // C++ generates a "function doesn't return value"  
warning
}

int result == foo();
assert(result == Success); // C++ generates a "variable is unused" warning

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

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

I believe you didn't understand what does "Stronger const" mean. Const is  
transitive in D and it is not in C++.
In C++, even if you pass a const object to some function, you can't be  
sure that it won't be changed:

struct Child;

struct Parent
{
    Child* child;
};

struct Child
{
    Parent* parent;
    int data;
};

void foo(const Parent* parent)
{
     Child* child = parent->child;
     child->data = 42;
     child->parent->child = 0; // const object is changed
}

Using macros for const objects is a bad idea, too, you should use enums  
instead. Too bad they are limited to numerical values in C++. In D you can  
use whatever you want:

enum Constants {
    Text = "Hello, World",
    Result = 42,
    Pi = 3.1415926,
}

etc.

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

You missed that one, again. You can have headers in D, too.

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

You can turn it off and do the memory management by yourself, if you wish:

struct Foo {}
Foo* foo = new Foo();
delete foo;

>> - No automatic copy constructor
>
> Can't comment.
>
>> - More restrictive operators
>
> I'm not really concerned about that. I'd avoid them unless doing  
> numerical
> programming.
>
>> - Delegates (Specifically, encouraging there use by making them simple  
>> to
>> use)
>
> Can't comment.
>

This is an awesome feature, too bad you don't have this one in C++. You  
will like it, believe me!

>> - Specific constructs such as Interfaces
>
> C++ has interfaces. Should it be a keyword? Maybe. How are D's interfaces
> different from C++'s?
>

C++ doesn't have interfaces, but you can emulate them (pretty badly)  
inheriting virtually from structs.

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

No, I don't get your point. Do you mean that you don't use C++ casts  
either (dynamic cast, int->float casts etc)? Why comment, then?

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

You don't need a preprocessor in most cases, but C++ lacks an alternative.

You may want to read this paper, too:  
http://www.digitalmars.com/d/sdwest/paper.html