On Wed, Oct 20, 2021 at 05:28:30PM +0000, Guillaume Piolat via Digitalmars-d wrote: [...]
> One of the problem C++ has with objects-with-inheritance-as-value-type is "object slicing".
> 
> It is ugly in theory: https://stackoverflow.com/a/14461532
> 
> I guess it's one of the reason D doesn't have that, so a discussion about Object* needs to address that issue.

Yes, I believe the original reason D treats classes as inherently by-reference is precisely because of this. Consider:

	class A {
		int x;
		virtual int getValue() { return x; }
	}
	class B : A {
		int y;
		override int getValue() { return y; }
	}

	B b;
	A a = b; // allowed since B is a subtype of A.
	writeln(a.getValue()); // uh oh

Assume by-value semantics for the sake of argument.  So `a` gets a copy of part of B, because there is only enough space allocated on the stack to store an A but not a B. So `y` is missing.  Then what should a.getValue return?  Since it is virtual, it should call B.getValue, which accesses a non-existent member, or in more practical terms, it reads from the stack outside of the bounds of A.

All sorts of subtle (and nasty) problems crop up when you mix polymorphic class objects with by-value semantics.  That's why D's design makes more sense: if you want OO-style inheritance, let it be by-reference all the way. If you want by-value semantics, which is incompatible with OO-style polymorphism, use a struct.  Simple solution, avoids all the nastiness you have to deal with in C++.


T

-- 
Never step over a puddle, always step around it. Chances are that whatever made it is still dripping.

On Wednesday, 20 October 2021 at 17:28:30 UTC, Guillaume Piolat wrote:
> On Wednesday, 20 October 2021 at 11:41:32 UTC, Adam D Ruppe wrote:
>>
>> I don't really think it is worth the hassle but it is interesting in that it solves some old syntax worries.
>
> One of the problem C++ has with objects-with-inheritance-as-value-type is "object slicing".
>
> It is ugly in theory: https://stackoverflow.com/a/14461532

Never had any issues with this in real life, this is one of many things you should think about when modelling.

The real "problem" with C++ is that it both provides a lot of flexibility-for-responsible-designers, but also provides defaults. Since people don't write the default it is easier to forget to adjust the semantics of all member functions to the model.

On 10/20/21 11:02 AM, Ola Fosheim Grøstad wrote:
> On Wednesday, 20 October 2021 at 17:28:30 UTC, Guillaume Piolat wrote:

>> One of the problem C++ has with objects-with-inheritance-as-value-type
>> is "object slicing".
>>
>> It is ugly in theory: https://stackoverflow.com/a/14461532
>
> Never had any issues with this in real life,

Me neither because I was following convention in C++: "Pass inherited types by reference because there is slicing." That rule renders C++ classes (and structs) of inheritance hierarchies "reference types". I like D's (and Java's and C#'s) approach here.

Ali

On Wednesday, 20 October 2021 at 15:58:49 UTC, Adam D Ruppe wrote:
> On Wednesday, 20 October 2021 at 15:53:53 UTC, H. S. Teoh wrote:
>> Object* *is* the pointer.  There's nothing going on behind the scenes.
>
> well tho does obj++; move the pointer or call the operator on the class?
>
> I don't think this syntax is ideal (I kinda prefer the old `Object ref` proposal), but just it is something interesting to think about.

FWIW the 'non-nullable & explicitly nullable pointers' proposal resolves this.  Because the point of such pointers is that they always point at exactly one object (or at nothing), there is no point in indexing or adding anything to them etc., so such overloaded operators can be forwarded.  (As x.y -> (*x).y, so x.opUnary!"++" -> (*x).upUnary!"++".)

However I just realised unary * can be overloaded.  Obviously *x should be a dereference.  But as that is a fairly fringe use case (and the point of the exercise was to ignore compatibility anyway), I think it can be safely steamrolled.