How does D improve design practices over C++?

[Tony]

"Jarrett Billingsley" <jarrett.billingsley at gmail.com> wrote in message 
news:mailman.354.1226008916.3087.digitalmars-d at puremagic.com...
> On Thu, Nov 6, 2008 at 4:18 PM, Tony <tonytech08 at gmail.com> wrote:
>> I like the header as the high level view of the code, be it classes or
>> functions or whatever.
>
> Documentation works quite nicely for that too.  Or an editor that's
> smart enough to collapse function/class bodies or to give you a list
> of declarations.

A header file IS documentation more often than formal documentation. That 
said, I have produced structural documentation for my own code with doxygen, 
but mostly I don't need that unless I get away from working with the code 
for a long period of time or I just want to see the diagrams. More times, 
the design and architecture documentation that I have in the headers for now 
is much more useful. I was building an outlining code editor until MS VS 7 
came out. I like that IDE a lot now that I have my preferences set in it. 
Out of the box settings are all about marketing MS technologies that I don't 
use (.net etc).

>
>>> This also makes compilation times much faster, since the header files
>>> don't need to be included & recompiled during every compilation -- if
>>> you're compiling a group of files that depend on one another at once, 
>>> the
>>> compiler will only compile each one once.
>>
>> Compile times as I am not doing large scale development. And with so much
>> processor power available these days, I really don't see a problem with
>> compile times. Some care in laying out code and headers goes a long way.
>
> Boost.

What about it?

>
>>> Then you use the GC. Or malloc/free. Or placement new. Or... seriously,
>>> what do you want here?
>>
>> OK. I was just wondering how C++ like those things were in D. Apparently
>> pretty much the same, if not exactly so even.
>
> Yeah.  D uses GC by default, but there's nothing stopping you from
> turning it off, or compiling your app with a stub GC that doesn't
> actually do GC, or using malloc/free, or whatever floats your boat.
> It has custom allocators/deallocators just like C++ as well.
>
>> In C++:
>>
>> int GetAnInt()
>> {
>>    static int i = 0;
>>    return ++i;
>> }
>>
>> So what kind of major programming problems do delegates and closures 
>> solve?
>> Are they just syntactic sugar?
>
> No, not at all.  Your example works in this case, but the point of a
> closure is that it is almost like an object - it is allocated on the
> heap, and has its own state.  So while your example will indeed return
> a sequence of integers upon successive calls, what the closure version
> does that your code can't do is have _multiple_ counters.  You call
> getADelegate() multiple times, and each delegate will have _its own
> state_, meaning that each delegate is a different object, and will
> generate its own sequence of numbers upon successive calls.  Your
> function only has a single global state variable and cannot do the
> same.

That's what I saw also. Thx for confirming. I guess I'd have to actually 
have that available to me to get my mind to consider it as I was coding. 
Would I put it in my language? I dunno.

class GetAnIntClass
{
    int X;
public:
    GetAnIntClass(){ X = 0; }
    int GetAnInt(){ return ++X; }
};

>
> Delegates are kind of similar to the new [](){} function literals that
> are coming out in C++0x, except more automatic and, from what I
> understand, more powerful.  For example, and correct me if I'm wrong,
> C++0x's function literals cannot directly access the stack frame of
> the enclosing function; you have to "capture" them inside the square
> brackets.  D's nested functions (which are delegates) are allowed to
> access and modify their enclosing function's stack frame.  This makes
> writing things like callbacks _so_ much less painful.
>
> Lastly delegates don't have to be just free functions; they also act
> as a stand-in for pointers-to-member-functions.  If you do something
> like
>
> auto obj = new Class();
> auto dg = &obj.someMethod;
>
> dg is a delegate that points to 'obj' and 'someMethod'.  When you call
> dg(), it's the same as doing obj.someMethod().