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

Reply via email to