Quote:
an_a->bar(); //calls A::bar, but an_a is pointing to a B instance which overloads the bar() method
I can't think of any situation where the above behaviour would actually be useful.
🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
AngelScript - polymorphism, interfaces, and inheritance
You're correct. But can you think of any situation where it would be useful not to declare the method as virtual in the base class when you're overloading it in the derived class?
I can't think of any situation where the above behaviour would actually be useful.
I can't think of any situation where the above behaviour would actually be useful.
well, you might not even want virtual calls.
You might want.
class A
{
protected:
string name;
public:
string get_Name(){return name;}
string set_Name(string N){name = n;}
class B : public A
{
.. code
}
B b;
b.set_Name("my new name");
You might want.
class A
{
protected:
string name;
public:
string get_Name(){return name;}
string set_Name(string N){name = n;}
class B : public A
{
.. code
}
B b;
b.set_Name("my new name");
also, I think multiple inheritance is cool and interfaces are cop-outs.
The decision then is does MI really belong in script language. I think that it would be nice.
The decision then is does MI really belong in script language. I think that it would be nice.
I know that if you're not doing any overloading of methods then you shouldn't declare the methods as virtual. But this is not my doubt, my doubt is when would you want to _not_ declare a method as virtual but still want to overload it.
I have a chance to leave it up to the compiler whether to automatically declare a method as virtual or not. It would then declare all methods that are overloaded as virtual and thus save the script writer from having to worry about that. This is of course assuming that it would never be necessary to have non-virtual methods that are still overloaded.
I too think that multiple inheritance can be useful in some cases and it doesn't incur much overhead for C++. The way the script classes work however, it wouldn't be as easy to implement, and it would incur a much larger overhead. Maybe in the future I'll find a better solution for the script class, that would make multiple inheritance possible, but at the moment I won't even try it.
Regards,
Andreas
I have a chance to leave it up to the compiler whether to automatically declare a method as virtual or not. It would then declare all methods that are overloaded as virtual and thus save the script writer from having to worry about that. This is of course assuming that it would never be necessary to have non-virtual methods that are still overloaded.
I too think that multiple inheritance can be useful in some cases and it doesn't incur much overhead for C++. The way the script classes work however, it wouldn't be as easy to implement, and it would incur a much larger overhead. Maybe in the future I'll find a better solution for the script class, that would make multiple inheritance possible, but at the moment I won't even try it.
Regards,
Andreas
In java, interface methods cannot have definitions. Would it be too hard to get around this, but keep it similar otherwise?
It's one thing that bugs me about java interfaces, it seems it's preferable to make something an interface so that types that derive from another superclass can use it.
But in doing so you lose out the "code reuse" part of OO, because you cannot give definitions to these methods in the interface.
If I'm making some sense let me know.
It's one thing that bugs me about java interfaces, it seems it's preferable to make something an interface so that types that derive from another superclass can use it.
But in doing so you lose out the "code reuse" part of OO, because you cannot give definitions to these methods in the interface.
If I'm making some sense let me know.
Allowing implementations in the declaration of the interfaces would effectively make it multiple inheritance.
With interfaces, the derived class doesn't actually inherit anything, not even virtual methods. The interfaces is only a way to tell the compiler that the class is guaranteed to have that set of methods, so that the object can be passed to a function that needs to call those methods on the object.
The code reuse can be solved in other ways than inheritance. You could for example use mix-in, which is what the D language does. Macros is another way that works.
With interfaces, the derived class doesn't actually inherit anything, not even virtual methods. The interfaces is only a way to tell the compiler that the class is guaranteed to have that set of methods, so that the object can be passed to a function that needs to call those methods on the object.
The code reuse can be solved in other ways than inheritance. You could for example use mix-in, which is what the D language does. Macros is another way that works.
It's important to remember that public inheritence - what allows for polymorphism - is NOT a tool for code re-use in C++. It models an 'is-a' relationship between the derived and parent classes. Code re-use calls for an 'is-implemented-in-terms-of' relationship, and would use private inheritence or containment.
In short, your argument about Java's 'strange' limitations on interface classes is flawed because your understanding of the concept they represent is flawed.
In short, your argument about Java's 'strange' limitations on interface classes is flawed because your understanding of the concept they represent is flawed.
Quote: Original post by Deyja
It's important to remember that public inheritence - what allows for polymorphism - is NOT a tool for code re-use in C++. It models an 'is-a' relationship between the derived and parent classes. Code re-use calls for an 'is-implemented-in-terms-of' relationship, and would use private inheritence or containment.
In short, your argument about Java's 'strange' limitations on interface classes is flawed because your understanding of the concept they represent is flawed.
Oh no. I thought code reuse meant reusing code. Sorry for my very stupid post.
Change may statement to be about "reusing code" instead.
Any complaints now?
@WitchLord
I confess to not using angel script, but depending on how you will implement virtual methods (hence my comment: "Would it be too hard to get around this" ) I can't see this being impossible.
Maybe its just me, but I think most of the problems in multiple inheritance come from the memory layout of the objects, particularly when passing them as one of their super types.
I mean, if you go the vtable way, you will need to know which method in an object corresponds to the ones in the interface anyway...
I'm not planning on using vftables to resolve the interface methods, exactly because of the problem with the memory layout question due to multiple inheritance. I'll use something slower, but easier to implement to start with. Maybe in the future I'll look for a faster solution, if it's worth it.
I'll probably use vftables for the virtual methods inherited through single inheritance though, as this is the fastest and easiest way to do it.
Regards,
Andreas
I'll probably use vftables for the virtual methods inherited through single inheritance though, as this is the fastest and easiest way to do it.
Regards,
Andreas
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
