There's no ned for that! It's possible with nothing but a reference-shematics operator= for the class Base. Since references are basicly pointers that act like objects, polymorphism works, so both derived1 and Derived2 can be assigned to eachother and Base.
There is one more restriction which I forgot to mention. Apologies for that.
The Base and the two Derived classes are all generated by some ASN compiler. So I cannot make any changes to the class. Now how do I get this done without making any changes to any of the classes?
There is one more restriction which I forgot to mention. Apologies for that.
The Base and the two Derived classes are all generated by some ASN compiler. So I cannot make any changes to the class. Now how do I get this done without making any changes to any of the classes?
I think I can use reinterpret_cast. But I am not sure how safe is that?
@vinaynaikwad: Dind't you hear me? You can use the predefined assignment operator! EVEREY assignment operator shall take a reference, so it MUST work!
@Telion: Really?
That is, it may compile (I'm not sure), but only animal::operator=() will get called, thus only animal's members will get set. dog's members will be left in an inconsistent state.
@Zephilinox
My base class doesn't have any set/get methods. And the derived classes have one public variable each whose enum value is same.
I have Derived2 object which I need to pass to a function that accepts Derived1 object. I tried using reinterpret_cast as below:
Derived1 supports 3 enum values: locked, shuttingdown and unlocked.
Derived2 supports 2 enum values: locked and unlocked.
Derived1* d1 = reinterpret_cast<Derived1 *> d2;
But when I dereferenced d1, it had some other value. Like, when d2 had unlocked, after re-interpret casting, d1 was having locked sometimes, unlocked the other time and also shuttingdown sometimes.
You suspect any problem with the way I am using reinterpret_cast?
if d2 doesn't have shuttingdown, then it shouldn't be passed to a function that expects d2, at least I think it shouldn't, because shuttingdown would be undefined if that function were to try and access it.
maybe it simply isn't possible, or has your teacher(?) said otherwise?
@Zephilinox
I got the problem.
Derived1 has these values: locked(0), unlocked(1), shuttingDown(2).
Values in the brackets are corresponding enum values.
Derived2 has: locked(1), unlocked(2).
When I reinterpret_cast d2 to d1, and when d2 is locked(1), the corresponding d1 values would be unlocked(1). And when d2 is unlocked(2), the corresponding d1 afetr casting is shuttingDown(2). Hence the problem is with enum values.
Not safe at all. It is effectively you insisting to the compiler that it forget everything it knows and treat an object as if it were a different kind of object, no matter what. No converting is done, no considerations taken. This pattern of bits that five seconds was this kind of object; now pretend it's that kind of object.
reinterpret_cast is the same as making an anonymous union, whose first member is of the type that you are casting from, and the second one is the one you are casting to, then you assign the value of the first type that you want to reinterpret_cast from to the first member, and then use the second member as the reinterpret_casted value.
You are trying to assign a cat to a dog, ¿what the hell do you expect to happen?
Well, of course in the general case it doesn't make sense, but that's not to say that there are no special cases where operator=() could perform some sort of conversion between objects of different types.
For example, suppose you have Bezier and Circle, which are both kinds of Curves. A Bezier curve has nothing that even remotely resembles a center or a radius, but it can be used to approximate a circle, so it would be nice if you could do that by just doing an assignment.