Larry Luther:

I'm nonplussed. Could you expand on why D class instances don't need to copy their contents and instances of D structs do?  While migrating C++ code to D I've had to convert "struct"s to "class"es because of the need for inheritance.  Why would the need to copy an instance's contents to another instance disappear?<

You are an experienced programmer, so if you think well about this topic you can probably understand the situation and the purposes behind D design as well or better than me. You probably know already what I can tell you about this topic.

D is different from C++, it's GC-based, and this changes many things and the way they have to be designed and used. D is designed to be a little "simpler" than C++, this means in some cases it prefers to do something in a safer way, instead in the most efficient way. D doesn't follow the zero overhead policy of C++, because it can lead to hairy code and because Java and C# have plenty shown it's often a waste of programmers time with no real performance gain.

In D structs don't support inheritance because they are designed to avoid the slicing bug, to be simpler, to be Plain Old Data. So D is designed to have different classes and structs because their usage style and purposes are different. When more complexity is needed, classes are there to be used. Even if currently DMD is not very good at optimizing away the class-derived overhead, better future D compilers can solve this. For some situations there's even the "scope" (that Walter is not so sure to keep, while other people like me have suggested the opposite, that is to extend its purpose to allocate an object inside the memory of another object) that can help performance. In Java the HotSpot is able to perform Escape Analysis on objects to avoid many heap allocations, and LDC is able to detect some simple cases and do the same.

By design D has no standard way to copy classes. I have not written very large object oriented D programs, but from what I have seen, I generally don't need to copy objects. I have often the need to move them around, put them in a collection, pull them out and put them in another collection, or create them in single instance, and so on. But I don't remember the last time I've had to copy a class instance in D. I just copy and add and remove class references. When I want I can keep many references to the same object and so on. In C++ programs this has to be done with care, because there is no GC, or you need some kind of smart pointer, while in D (in theory) you can relax and just let the GC do its thing.

My experience tells me that when you try to translate a program written in language X to language Y you always find some impedance (unless X and Y are almost the same language). But most times in language Y there are ways to solve the problem in a different way. You, as programmer, have to learn the way Y programs are usually written, its idioms and to avoid to force X idioms in Y and then complain that X idioms are not well represented in Y.

D design is far from perfect, and in future some things will probably need to be fixed (I have written enough text to fill two books about D features that can enjoy some change), but behind its design there is also lot of thought. So, you can show us some D code where you think there is a need to copy objects. If such uncommon need arises you can usually write your own copy functions.

Bye,
bearophile

Larry Luther:

>Ok, I've added -w to compilation commands and I've switched back to pure text.<

Good :-)


>What am I missing?<

I have modified a bit your D code like this, to have something with a main() that runs:


import std.c.stdio: puts;

class A {
    int x, y;

    void copy(const A a) {
        puts("A copy");
        x = a.x;
        y = a.y;
    }
}

class B : A {
    int z;

    void copy(const B b) {
        puts("B copy");
        super.copy(b);
        z = b.z;
    }
}

void main() {
    A a1 = new A;
    A a2 = new A;

    B b1 = new B;
    B b2 = new B;

    a1.copy(a2); // should execute A.copy
    a1.copy(b1); // should execute A.copy
    b1.copy(b2); // should execute B.copy
    b1.copy(a1); // should execute A.copy
}



I have also translated your the code to Java, because sometimes Java designers are more "correct" thant D designers:


class A {
    int x, y;

    void mycopy(A a) {
        System.out.println("A mycopy");
        x = a.x;
        y = a.y;
    }
}

class B extends A {
    int z;

    void mycopy(B b) {
        System.out.println("B mycopy");
        super.mycopy(b);
        z = b.z;
    }

    public static void main(String[] args) {
        A a1 = new A();
        A a2 = new A();

        B b1 = new B();
        B b2 = new B();

        a1.mycopy(a2); // should execute A.mycopy
        a1.mycopy(b1); // should execute A.mycopy
        b1.mycopy(b2); // should execute B.mycopy
        b1.mycopy(a1); // should execute A.mycopy
    }
}


The Java code compiles and runs with no errors, and prints:
A mycopy
A mycopy
B mycopy
A mycopy
A mycopy


But the D version is different. It seems you have found a small difference between Java and D that I didn't know about.

If I comment out the last line of the main() in the D code (b1.copy(a1);) and I compile the D code with -w it generates the warning I was talking about:

test.d(13): Error: class test.B test.A.copy(const const(A) a) is hidden by B


If I leave that line uncommented then the compilation stops with a different error:

test.d(33): Error: function test.B.copy (const const(B) b) is not callable using argument types (A)
test.d(33): Error: cannot implicitly convert expression (a1) of type test.A to const(B)

It seems in D the copy() of B replaces (hides) the copy() of A, even if no override is used. I don't know why D is designed this way, it can even be a design/implementation bug. But the presence of that warning suggests me this is expected, so it's probably just a difference between Java and D. If no one answers to this here then maybe later I will ask about this in the main D group.

Bye,
bearophile

See: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=110554

"bearophile" <bearophileHUGS@lycos.com> wrote in message
news:ht4krg$17l9$1@digitalmars.com...
| On the base of your long experience do you like D so far?

There are many things that I like and I strongly agree with the failings
of C++ mentioned in the docs.  I don't like the asymmetry between structs
and classes.  I don't see why structs can't have inheritance.  I haven't
had a memory leak problem in C++ for many years so the need for a GC seems
minor.
I can only assume that it's needed to support strings and dynamic arrays.
I'm pushing forward on the assumption that I'll discover the paradigm that
will make everything fall into place.  It's hard to get the proper picture
from the documentation available on Digital-mars.  "Tango with D" didn't
significantly help either.  For example it took a great deal of time to
learn
that "private" can be used several ways:

  private member_function () {)

  private {
    member_function () {}
  }

  private:
    member_function () {}

  I'm anxiously waiting for something of the quality of the "Annotated C++
Reference Manual".

Larry

Larry Luther:

> There are many things that I like and I strongly agree with the failings of C++ mentioned in the docs.

D is designed by people that have a good experience of C++, but while probably D avoids some C++ problems, it surely introduces a number of new issues :-)


> I don't like the asymmetry between structs
> and classes.  I don't see why structs can't have inheritance.

One of the first answers given here is that this D design avoids slicing bugs. See my other answer for more.


> I haven't
> had a memory leak problem in C++ for many years so the need for a GC seems
> minor.
> I can only assume that it's needed to support strings and dynamic arrays.

A GC introduces other kind of leaks when there is a reference alive to an memory block that is supposed to be dead and not used any more. This can even be caused by the not precise nature of the current D GC, it can mismatch something for a pointer to a GC-managed memory zone, keeping it alive. For example in programs that use large associative arrays this seems a problem.

If you assume the presence of the GC this changes the way you write code. In theory you can be more relaxed. In practice D GC is not... well, you have to keep your eyes open anyway.


> I'm pushing forward on the assumption that I'll discover the paradigm that will make everything fall into place.

If you have some Java programming experience then you probably have nothing to discover regarding this aspect of D programming (here the main difference is that Oracle Java GC is more precise and quite more efficient).


> For example it took a great deal of time to learn that "private" can be used several ways:

One of the good things of D design is that it tries to be uniform/consistent, in this case all other attributes can be used in the same ways :-)


>   I'm anxiously waiting for something of the quality of the "Annotated C++
> Reference Manual".

The problem here is that D is not very strictly defined in the first place, so it's harder to write a very strict D reference manual :-) But Andrei book is about to come out, that can be seen as a kind of official D2 reference.

Bye,
bearophile

On Thu, 27 May 2010 17:04:35 -0400, Larry Luther <larry.luther@dolby.com> wrote:

> "bearophile" <bearophileHUGS@lycos.com> wrote in message
> news:ht4krg$17l9$1@digitalmars.com...
> | On the base of your long experience do you like D so far?
>
> There are many things that I like and I strongly agree with the failings
> of C++ mentioned in the docs.  I don't like the asymmetry between structs
> and classes.  I don't see why structs can't have inheritance.

Because of the slicing problem.  It's basically something like this:

struct A {virtual void foo();};

struct B : A {virtual void foo();};

void bar(A a)
{
  a.foo();
}

void baz()
{
  B b;
  bar(b); // b is "sliced" down to an A, and bar will now call A.foo instead of the expected B.foo.
}

The really bad part about this is, b might have set up its private variables so that to call A.foo would cause an error.

Same thing happens when returning by value.  The general issue is that inheritance and value types don't mix.  But reference types (that is, types that are always passed by reference) never have the slicing problem.  So classes in D (which are reference types) can inherit, while structs (which *can be* value types) cannot inherit.  I have hoped that at some point, structs can be auto-composed, without a vtable, but you still have to do this manually.  Luckily, it's not so much of a chore now that alias this is around.

>  I haven't
> had a memory leak problem in C++ for many years so the need for a GC seems
> minor.
> I can only assume that it's needed to support strings and dynamic arrays.
> I'm pushing forward on the assumption that I'll discover the paradigm that
> will make everything fall into place.

Yes, what it took for me is to write a project in C++ that could really have used a GC.

Essentially, here was my issue:

I had a protocol implemented with various messages with a function readMessage, which returned a newly-allocated message (which was a derivative of some base message type).  Then I used RTTI to cast the message to the right type to deal with the data.  However, what sucked is how I always had to free the message after receiving it.  I really just wanted to process the message and go to the next one.  A GC is great for this because memory management is not strewn throughout your code, you don't have to remember to free things you should free and leave things you should not.  On top of that, in my case, I had to figure out that I was responsible for freeing a message via documentation -- the language didn't really tell me.  In D, no matter where it comes from, you just forget about it, and whoever is responsible (GC or owner) cleans it up later.  It makes for much more readable and less error-prone code.

There are many other designs which work well with GC, and some which don't.

D has some power over the memory management so you can force your will upon it, but I've found that the best way to write D code is to embrace the GC.

Note also that memory leaks are not the worst problem with non-GC code.  Freeing memory you weren't supposed to is worse.

>   I'm anxiously waiting for something of the quality of the "Annotated C++
> Reference Manual".

The D Programming Language is hitting bookstores soon, I think it will be a very good reference and educational book.

-Steve

Steven Schveighoffer:
> I have hoped that at some point, structs can be auto-composed, without a vtable, but you still have to do this manually.

I don't understand what you mean here :-)

Bye,
bearophile

bearophile wrote:
> Larry Luther:
> 
>> Ok, I've added -w to compilation commands and I've switched back to pure text.<
> 
> Good :-)
> 
> 
>> What am I missing?<
> 
> I have modified a bit your D code like this, to have something with a main() that runs:
> 
> 
> import std.c.stdio: puts;
> 
> class A {
>     int x, y;
> 
>     void copy(const A a) {
>         puts("A copy");
>         x = a.x;
>         y = a.y;
>     }
> }
> 
> class B : A {
>     int z;
> 
>     void copy(const B b) {
>         puts("B copy");
>         super.copy(b);
>         z = b.z;
>     }
> }
> 
> void main() {
>     A a1 = new A;
>     A a2 = new A;
> 
>     B b1 = new B;
>     B b2 = new B;
> 
>     a1.copy(a2); // should execute A.copy
>     a1.copy(b1); // should execute A.copy
>     b1.copy(b2); // should execute B.copy
>     b1.copy(a1); // should execute A.copy
> }
> 
> 
> 
> I have also translated your the code to Java, because sometimes Java designers are more "correct" thant D designers:
> 
> 
> class A {
>     int x, y;
> 
>     void mycopy(A a) {
>         System.out.println("A mycopy");
>         x = a.x;
>         y = a.y;
>     }
> }
> 
> class B extends A {
>     int z;
> 
>     void mycopy(B b) {
>         System.out.println("B mycopy");
>         super.mycopy(b);
>         z = b.z;
>     }
> 
>     public static void main(String[] args) {
>         A a1 = new A();
>         A a2 = new A();
> 
>         B b1 = new B();
>         B b2 = new B();
> 
>         a1.mycopy(a2); // should execute A.mycopy
>         a1.mycopy(b1); // should execute A.mycopy
>         b1.mycopy(b2); // should execute B.mycopy
>         b1.mycopy(a1); // should execute A.mycopy
>     }
> }
> 
> 
> The Java code compiles and runs with no errors, and prints:
> A mycopy
> A mycopy
> B mycopy
> A mycopy
> A mycopy
> 
> 
> But the D version is different. It seems you have found a small difference between Java and D that I didn't know about.
> 
> If I comment out the last line of the main() in the D code (b1.copy(a1);) and I compile the D code with -w it generates the warning I was talking about:
> 
> test.d(13): Error: class test.B test.A.copy(const const(A) a) is hidden by B
> 
> 
> If I leave that line uncommented then the compilation stops with a different error:
> 
> test.d(33): Error: function test.B.copy (const const(B) b) is not callable using argument types (A)
> test.d(33): Error: cannot implicitly convert expression (a1) of type test.A to const(B)
> 
> It seems in D the copy() of B replaces (hides) the copy() of A, even if no override is used. I don't know why D is designed this way, it can even be a design/implementation bug. But the presence of that warning suggests me this is expected, so it's probably just a difference between Java and D. If no one answers to this here then maybe later I will ask about this in the main D group.
> 
> Bye,
> bearophile

For what it's worth, here is a code that uses 'dup' instead of 'copy'. I know this is not the same thing; but I find this more intuitive:

import std.stdio;
import std.string;

class A
{
    int x, y;

    this(int x, int y)
    {
        this.x = x;
        this.y = y;
    }

    A dup() const
    {
        writeln("A copy");
        return new A(x, y);
    }

    override string toString() const
    {
        return format("A(%s,%s)", x, y);
    }
}

class B : A
{
    int z;

    this(int x, int y, int z)
    {
        super(x, y);
        this.z = z;
    }

    override B dup() const
    {
        writeln("B copy");
        return new B(x, y, z);
    }

    override string toString() const
    {
        return format("B(%s,%s,%s)", x, y, z);
    }
}

void main() {
    A a1 = new A(1, 1);
    A a2 = new A(2, 2);
    B b1 = new B(11, 11, 11);
    B b2 = new B(22, 22, 22);

    a1 = a2.dup;
    assert((a1.x == 2) && (a1.y == 2));

    a1 = b1.dup;
    assert((a1.x == 11) && (a1.y == 11));
    assert(typeid(a1) == typeid(B));      // <-- personality change

    b1 = b2.dup;
    assert((b1.x == 22) && (b1.y == 22) && (b1.z == 22));

    // b1 = a1.dup; // <-- ERROR because not all As are Bs;
    //                           but as we know that a1 is
    //                           actually a B at this point;
    //                           we can down cast:
    assert(cast(B)a1 !is null);
    b1 = (cast(B)a1).dup;
    assert((b1.x == 11) && (b1.y == 11) && (b1.z == 11));

    writeln(a1);
    writeln(a2);
    writeln(b1);
    writeln(b2);
}

Ali

On Thu, 27 May 2010 17:47:20 -0400, bearophile <bearophileHUGS@lycos.com> wrote:

> Steven Schveighoffer:
>> I have hoped that at some point, structs can be auto-composed,
>> without a vtable, but you still have to do this manually.
>
> I don't understand what you mean here :-)

I mean simple inheritance.  In C, there has always been manual inheritance.  You can see it with the sockaddr system, and even with the X toolkit widget system.

essentially, when you derive type B from type A in C++, you get this:

struct B
{
   A _a;
}

A is always put first, that way, a pointer to a B can always be used as a pointer to an A.

The other thing that happens is that function calls on B also use A as well.  This is not so easy in C, but in D it is currently quite trivial:

struct B
{
   A _a;
   alias _a this;
}

Then a call like b.methodOfA(); gets translated statically to b._a.methodOfA().

But there are things I don't like about this, such as you can *set* _a.  To get around that, you define a property getter, but not a setter:

struct B
{
   private A _a;
   @property ref A a() {return _a;}
   alias a this;
}

What I would like is a common-sense approach to inheritance for structs that just does not allow virtual methods or interfaces, and which does not cast implicitly to the base (explicit cast is OK).  I think some designs would benefit greatly from this simple feature.  I think it's more tricky than I've described, but I think with some diligence it can be done.

-Steve

Ali:
> For what it's worth, here is a code that uses 'dup' instead of 'copy'.

Oh, right. I have forgotten to say this to the OP. In D it's better to name it dup instead of copy.


>I know this is not the same thing; but I find this more intuitive:<

I agree, it's better for D.


>      A dup() const

Probably this is better, seeing your usage of it:

@property A dup() const

Bye,
bearophile