How does D improve design practices over C++?

[Tony]

"Denis Koroskin" <2korden at gmail.com> wrote in message 
news:op.uj3j16t7o7cclz at worker...
> 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.

Yes, unit testing is necessary. I see no need to make it a language feature 
though.

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

What I meant was that formalism is not necessary for the concepts. Eiffel 
wasn't the creator of DbC techniques. Do precondition checking? Sure. In the 
rare instances that an invariant can be had, use it? Sure.

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

Ah, OK, I get it. Yeah, that is good. But it is a minor point compared to, 
say memory management, OO model, generic programming facilities, for 
examples. The BIG features are what I am concerned about.

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

Yes, I don't really know "modules" other than what they obviously imply: 
separate compilation units/namespaces?

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

And if I don't want to use new and delete?

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

Well what the heck is it?!

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

Pure virtual abstract base classes are interfaces in C++. They work fine for 
me and I use them.

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

I haven't found the need for them, so no.

> Why comment, then?

Because if I can't use C-style casts, it would be a bummer.

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

I find the preprocessor useful as a template implementation machine.

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

OK. Not right away though. I have to rework more of my C++ framework.

Tony