what was wrong with struct & class in C++?
Yigal Chripun
yigal100 at gmail.com
Sun Dec 16 06:10:53 PST 2007
Bill Baxter wrote:
> Walter Bright wrote:
>> Christopher Wright wrote:
>>> That would be allowed in D, if you could overload T.opAssign(T).
>>
>> C++ still has well-known slicing problems, even with overloading
>> assignment.
>>
>> The question is not "can this be done", it's more "is there a
>> compelling reason to support such behavior". I think the answer is no.
>> Do you really want a language where a class designer feels compelled
>> to define an opassign overload, then make it private to prevent people
>> from using the class as a value type? Where the base class designer
>> needs to know what the derived classes are doing so he can make the
>> destructor virtual or not? Where you cannot have arrays of base classes?
>
> At least C++ lets you control copying behavior completely in all
> circumstances. And documents what you are supposed to do clearly. Right
> now D gives you the choice of
>
> 1) [structs] copy by value only, with no option to customize or
> intercept copy operations
> 2) [classes] no defined copy behavior whatsoever
>
> 1) makes interesting ref counting wrappers etc impossible, but I think
> you're planning to fix that one.
>
> I think 2) is a problem also. It means that developers will each come
> up with their own way to copy objects because there's no clear way to do
> it. I think some particular scheme should be crowned, like any class
> that wants to be copyable should provide a the pair of methods dup(),
> and copy(ThisType). And maybe there should be something in Object to
> this effect also, even if they don't do much of anything. Looks like
> java implements a clone() method in the base Object class. But it looks
> like that just makes it so you get a runtime exception if the class
> you're trying to clone doesn't support cloning. That doesn't seem like
> an improvement over a compile time error.
>
> So I'm not really sure what should be done, but I definitely think
> something should be done to specify "the D way" to polymorphically copy
> objects. Built-ins mostly have .dup properties, but I don't think the
> spec actually says anywhere that user classes that want to be copyable
> should have a .dup. But even specifying a .dup is not enough I think,
> because if I derive from some class A, I have to create my derived
> class, then get class A to copy the A parts of the new object somehow,
> say via a method like A.copy(A copy_from).
>
> C++ may have problems regarding copying classes, but D's solution is
> effectively to just remove the C++ functionality good and bad. Ok the
> slicing problem is gone, but so is copying. There should be one obvious
> way to make classes in D copyable, whether it be enforced by the
> language, compiler, or simply the spec and D community.
>
> --bb
In java you also need to implement a clonable interface which is a
marker interface.
I think that adding a clonable interface to the standard library should
be enough. something like:
---
interface clonable {
object dup();
}
---
now you need to implement it to support copying. I don't think a dup
method should be added to object. as you said, it isn't really an
improvement, and usually Java experts recommend avoiding clone().
also, i don't see why a copy method is required.
for example, check the following code:
---
class Base : clonable {
Base dup() {
auto ret = cast(Base) this.classinfo.create;
ret.x = this.x;
ret.y = this.y;
return ret;
}
int x = 6;
double y = 8;
}
class DerivedA : Base {
override DerivedA dup() {
auto ret = cast(DerivedA) super.dup;
ret.w = this.w;
return ret;
}
long w = 42;
}
More information about the Digitalmars-d
mailing list