25.1 Trait Objects diagram (Cat)

[njr0]

I might be misunderstanding here, but I was confused by the diagram. What is the box with a backslash through it? Is this indicating a null pointer? Is there a second pointer from Cat/pets[0] at all? And should the Dog and the Cat have ::name.

I might be being slow, but I found this diagram confusing.

[djmitche]

I have been wary of that diagram, too, reproduced here for reference

• I think the slash-box is meant to be a NULL pointer, indicating that no space is allocated for a ZST.
• The boxes with ::name in them are vtables, but that's not clear from the diagram.
• The name: Fido makes it look like the name is stored entirely within the struct, which isn't really true (but maybe not worth clarifying in the document).

What do you think we could do to improve the diagram?

[njr0]

I don't know because I don't really understand it. If the above is correct, then I suppose adding commentary to that effect is probably helpful. But I still don't really get it (which may well just be because I'm fairly new to Rust).

Something that probably is making this harder than it needs to be is the double use of name, both as a function name in the trait (and on the two structs, Dog and Cat) and also as the field name on Dog. I guess I'm reading the ::names not the Heap diagram as referring to the field, which I think it must be because that's what Fido is for the Dog instance. But Cat doesn't have that field.

So I think would be better to call the field dogname on Dog, so changing the code to:

trait Pet {
    fn name(&self) -> String;
}

struct Dog {
    dogname: String,
}

struct Cat;

impl Pet for Dog {
    fn name(&self) -> String {
        self.dogname.clone()
    }
}

impl Pet for Cat {
    fn name(&self) -> String {
        String::from("The cat") // No name, cats won't respond to it anyway.
    }
}

fn main() {
    let pets: Vec<Box<dyn Pet>> = vec![
        Box::new(Cat),
        Box::new(Dog { dogname: String::from("Fido") }),
    ];
    for pet in pets {
        println!("Hello {}!", pet.name());
    }
}

then I presume you'd have ::dogname on the right. But a cat clearly doesn't have a dogname, so I still don't understand what the second point from the Cat instance is.

If, on the other hand, the ::name is referring to the function (method) name...why is it Fido for the Dog.

pets is a vector of type Box of length 2 and capacity 2, stored on the heap. So the left box (the Stack) seems clear.

Each entry in the vector is a Box, which as I understand it is just a wrapper to cause a value to be stored on the Heap. In my copy of Programming Rust (2nd Ed, Bland, Orendorff, Tyndall), in the Ownership section of Chapter 4 (p. 83 in my copy), it has a diagram for a boxed pair (2-tuple) called point and it just points to the two values on the heap. So it doesn't seem like a Box has a second pointer in general. And I don't really seem what it would be for. Isn't the name on Dog another thing entirely, not with a pointer from the vector element?

I did find another diagram online that might help (a Google one, actually):

Rust container cheat sheet

The stuff on Boxes and Traits in the top right talks about vtables as you say. So if that's right, I think:

• the box with a backslash is probably a null pointer because cat doesn't need a vtable because it doesn't have any fields.
• It would be helpful to label the box with name: Fido as a vtable.
• I (still) think the ::names shouldn't be there on the Pets on the Heap
• If you agree that changing the name field on Dog to dogname would be helpful, the name: Fido on the Heap would obviously become dogname: Fido.

[mgeisler]

@djmitche is spot on with the interpretation of the diagram 😄

If, on the other hand, the ::name is referring to the function (method) name...why is it Fido for the Dog.

It is meant to refer to the name field of Dog.

The diagram is not as clear as I would like. The overall meaning that I try to convey is that a Vec<Box<dyn Pet>> is a vector of cell. Each cell has two pointers: a pointer to the underlying object (null pointer for Cat, actual pointer for Dog) and and a pointer to the vtable for the concrete type (Cat and Dog) and the trait (Pet).

Would it help if we add this information to the notes?

[njr0]

So if <Dog as Pet>::name refers to the field name in the Dog struct, what does <Cat as Pet>::name refer to?

If you called the field dogname (in the Dog struct) I think it would be clearer what's going on. Then, presumably, the label would become <Dog as Pet>::dogname.

It would make more sense if the ::name refers to the function (though the function isn't really on heap, presumably and the name: Fido would then be dogname: Fido.

Obviously, I'm confused, but I don't think adding this information to the notes would help, because the information still seems inconsistent to me. (Sorry.)

[mgeisler]

So if <Dog as Pet>::name refers to the field name in the Dog struct, what does <Cat as Pet>::name refer to?

Oh, sorry, I misunderstood above. <Dog as Pet>::name is supposed to refer to the Dog::name method.

If you called the field dogname (in the Dog struct) I think it would be clearer what's going on. Then, presumably, the label would become <Dog as Pet>::dogname.

It would make more sense if the ::name refers to the function (though the function isn't really on heap, presumably and the name: Fido would then be dogname: Fido.

Yeah, that is what the picture was supposed to show. I think "the heap" as "somewhere in memory". I guess the vtable is generated at compile-time and put somewhere in the binary — and then memory-mapped into the address space when the program is loaded from disk.

Obviously, I'm confused, but I don't think adding this information to the notes would help, because the information still seems inconsistent to me. (Sorry.)

No, I actually think you got it!

I suggest we change the name method to talk or speak in the Pet trait. The implementations can then be something like

impl Pet for Cat {
    fn speak(&self) -> String {
        String::from("Miau!")
    }
}

impl Pet for Dog {
    fn speak(&self) -> String {
        format!("Woof, my name is {}!", self.name);
    }
}

That would remove the name ambiguity. We should then also write notes to explain each part of the diagram.

[mgeisler]

I created #1292 for this.

[mgeisler]

and I've now created #1294 to try and improve on the diagram and the associated notes.

[njr0]

Brilliant. I'll understand Rust yet!

Thanks!