Why did D leave the programming language shootout and will it return?

Timon Gehr timon.gehr at gmx.ch
Tue Sep 20 16:58:29 PDT 2011


On 09/21/2011 01:37 AM, Walter Bright wrote:
> On 9/20/2011 4:24 PM, Timon Gehr wrote:
>> Basically, D code that does reasonably well at memory management is
>> fast. And it
>> is (way) easier to write fast D code than to write fast C++ code imho.
>> Once the
>> D compilers get more mature, I am sure that many D-specific
>> optimizations will
>> be added that cannot be performed on C++ code. (pure and immutable
>> come to mind)
>
> Once subtlety that Andrei and I suspect will have a huge impact in the
> future is that we've carefully designed the semantics of structs so they
> can be moved around in memory with a simple bitcopy.

Yes, I completely forgot about that, that is one of my favorite D features.

>
> (In contrast, C++ must invoke the copy constructor.)

C++11 rvalue references manage to make that effect somewhat less painful 
though.

>
> Two consequences are:
>
> 1. A moving garbage collector becomes practical.
>

And this is a requirement for highly efficient GC. How does it cope with 
pointers that point to memory not allocated on the GC heap though? Would 
the overhead of tracking references just be invasive on parts of the 
code that uses manual memory management if a program uses a moving GC?


> 2. An object can be "transferred". For example,
>
>
> void foo()
> {
> A x;
> ....
> bar(x);
> }
>
> Note that there is no use of x in foo() after the call to bar(x). Thus,
> x can simply be pushed onto the argument stack (i.e. a bitcopy) and
> bar() is called. bar() takes care of the destruction of x's copy.
>
> C++ is doomed to running the copy constructor for x to make a *copy* of
> it on the argument stack, and then must destroy the original x at the
> close of foo(). This costs:
>
> 1. an extra copy construction
> 2. an extra destructor call
> 3. extra exception handling & recovery code to deal with (1) throwing
>
> Think of it a bit like the Star Trek transporter. Does it actually do a
> bit transfer, or does it create a copy and destroy the original? As a
> red shirt, I'd prefer the D implementation of the transporter :-)



More information about the Digitalmars-d mailing list