5 ms·

Doesn’t Parent parent = Child() work because Parent’s constructor is run by implicitly casting ref-to-Child to ref-to-Parent?

fauigerzigerk 5y ago
I don't think that's enough, because Child() still results in an object that is sizeof(Child). In order to store that object in a variable that is sizeof(Parent) it has to be rejigged somehow. I think what TeeMassive is saying is that this rejigging is a simple truncation because the memory layout of (non virtual) inheritance in C++ is a concatenation of Parent and Child objects. I'm not sure whether this is implementation specific though.
- unkulunkulu 5y ago
  That’s certainly enough, if you can call a constructor, you don’t have to think about how it works and that the classes are related. The part about “rejigging” and simple truncation happens before the constructor call when you cast ref-to-Child to ref-to-Parent.
  - fauigerzigerk 5y ago
    There is no casting of references at all in Parent parent = Child().
    - unkulunkulu 5y ago
      Sorry for being afk and replying once in a while :/ Parent probably has a copy constructor Parent(const Parent& p) Parent p = Child(); calls it by implicitly casting Child& to const Parent&. That’s what happens. I see that you must have meant this casting step, so indeed the constructor has no control over the rejigging.
      - fauigerzigerk 5y ago
        I see what you mean, but let's go back to the orginal issue and why I think this implicit cast is insufficient as as definition of what happens here. Say you have the obvious minimal implementations of struct Point ... struct Point3D : public Point ... And then you do this: Point p3 = Point3D(1.1, 2.2, 3.3); Point p = p3; On a 64 bit machine this results in sizeof(p) == 16 and sizeof(p3) == 24. So, at some point someone has to decide how to transform p3's 24 byte representation into p's 16 byte representation. In C++, this happens simply by truncting p3, i.e copying the leading 16 bytes of p3 into p and throwing away the trailing 8 bytes (I'm not sure whether or not this is part of the standard). This is not the only imaginable way in which this could possibly happen though, which is why I'm saying that the whole process is not sufficiently defined by stating that a reference to child is cast to a reference to parent.

fauigerzigerk 5y ago

I don't think that's enough, because Child() still results in an object that is sizeof(Child). In order to store that object in a variable that is sizeof(Parent) it has to be rejigged somehow. I think what TeeMassive is saying is that this rejigging is a simple truncation because the memory layout of (non virtual) inheritance in C++ is a concatenation of Parent and Child objects. I'm not sure whether this is implementation specific though.

unkulunkulu 5y ago
That’s certainly enough, if you can call a constructor, you don’t have to think about how it works and that the classes are related. The part about “rejigging” and simple truncation happens before the constructor call when you cast ref-to-Child to ref-to-Parent.
- fauigerzigerk 5y ago
  There is no casting of references at all in Parent parent = Child().
  - unkulunkulu 5y ago
    Sorry for being afk and replying once in a while :/ Parent probably has a copy constructor Parent(const Parent& p) Parent p = Child(); calls it by implicitly casting Child& to const Parent&. That’s what happens. I see that you must have meant this casting step, so indeed the constructor has no control over the rejigging.
    - fauigerzigerk 5y ago
      I see what you mean, but let's go back to the orginal issue and why I think this implicit cast is insufficient as as definition of what happens here. Say you have the obvious minimal implementations of struct Point ... struct Point3D : public Point ... And then you do this: Point p3 = Point3D(1.1, 2.2, 3.3); Point p = p3; On a 64 bit machine this results in sizeof(p) == 16 and sizeof(p3) == 24. So, at some point someone has to decide how to transform p3's 24 byte representation into p's 16 byte representation. In C++, this happens simply by truncting p3, i.e copying the leading 16 bytes of p3 into p and throwing away the trailing 8 bytes (I'm not sure whether or not this is part of the standard). This is not the only imaginable way in which this could possibly happen though, which is why I'm saying that the whole process is not sufficiently defined by stating that a reference to child is cast to a reference to parent.