How does D improve design practices over C++?

[Jarrett Billingsley]

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.

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

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

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