void ADT_Cons(ADT *o)
{
new(o) ADT();
}
🎉 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!
Polymorphism in AngelScript
Author
I need to put something in my project that uses polymorphism, and I was wondering how well AS supported it, as I've heard many things about it not doing so. I decided to run a test myself first, and the results seems to suggest that it does indeed support polymorphism.
The sort of thing I'll be using will be a collection of ADT pointers in my C++ project. Let's say classes A and B each derive from ADT. I want AS to be able to grab an ADT pointer from the collection and call a function; if it's of class A, the function will do something different from one of class B (the function is virtual). In my test, I have successfully registered the ADT class and the derivative A and B classes, as well as the ADTCollection class and a specific ADTCollection object which holds all the games' A and B objects, which has a function to return an ADT pointer to whatever ADT derivative you want.
Though the test was successful and it does what I wanted it to, I wanted to ask if it fully supports polymorphism, or at least in the way I intend to use it. The reason I ask is because to return object handles to ADT objects, I had to register AddRef and Release behaviours, as well as a constructor behaviour. The constructor is this:
It's the "new ADT()" part that worries me. What if this needs to be done on an ADT pointer to a B object? Just wanted to make sure that everything will work as it should before I get heavy into this and later find out that something's gone terribly wrong.
Thanks!
You might be better off (Actually, you most definitely will) registering a wrapper class, rather than your ADT class. You could even use an ADT* as the wrapper (Not much of a wrapper - but, hey, what the hell does AngelScript care?)
If you register that, whenever you use 'ADT' in script, it will actually be an ADT* - but the script doesn't know this! All your application functions know they are getting ADT*s, and not ADTs, and can handle it fine. And you can still have ADT member functions in the script with a simple wrapper that forwards the call through the pointer.
In this scenario, writing functions to 'downcast' ADTs is trivial, as is supporting polymorphism (C++ will handle that, so you won't have to worry about whether or not AngelScript can at all).
Only caveat is that now you have to check for null. But, do that in the member func wrappers, not in the script.
If you register that, whenever you use 'ADT' in script, it will actually be an ADT* - but the script doesn't know this! All your application functions know they are getting ADT*s, and not ADTs, and can handle it fine. And you can still have ADT member functions in the script with a simple wrapper that forwards the call through the pointer.
In this scenario, writing functions to 'downcast' ADTs is trivial, as is supporting polymorphism (C++ will handle that, so you won't have to worry about whether or not AngelScript can at all).
Only caveat is that now you have to check for null. But, do that in the member func wrappers, not in the script.
AngelScript fully support virtual member functions for both classes with single inheritance and with multiple inheritance. It doesn't support member functions for classes with virtual inheritance, but I doubt your using that anyway.
As for the constructor behaviour, it will always call the constructor on previously uninitialized memory allocated just for this object, so you won't ever get a situation where calls the constructor for class B on memory allocated with enough space only for class A.
The memory that o points to in the constructor, is not yet initialized, it hasn't been defined as either A or B, that's what the new(o) ADT() statement will do. Only after the constructor has been executed does the memory has a type definition.
As for the constructor behaviour, it will always call the constructor on previously uninitialized memory allocated just for this object, so you won't ever get a situation where calls the constructor for class B on memory allocated with enough space only for class A.
void ADT_Cons(ADT *o){ new(o) ADT();}The memory that o points to in the constructor, is not yet initialized, it hasn't been defined as either A or B, that's what the new(o) ADT() statement will do. Only after the constructor has been executed does the memory has a type definition.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
