Shared-pointer-like behavior
Does AngelScript offer any possibility of making some kind of shared pointer between the script and the C++ application?
Let me explain, I have a script that may hold some object handles from objects that were originally instantiated in the application (actually they are in a STL list), is it possible to "nullify" the pointers in script automatically whenever any instance is destroyed in the application?
If it's not possible, what do you suggest?
Thanks in advance.
Yes.
You would want to register the type as a reference type and in doing that you would need to register the behaviors asBEHAVE_ADDREF and asBEHAVE_RELEASE. You just need a reference counter that is incremented on ADDREF and decremented on RELEASE.
You may want to take a look at this.
You would want to register the type as a reference type and in doing that you would need to register the behaviors asBEHAVE_ADDREF and asBEHAVE_RELEASE. You just need a reference counter that is incremented on ADDREF and decremented on RELEASE.
You may want to take a look at this.
Thanks, I read that. I just can't see how even with a reference counter the scripting machine would know when an instance created in the application was destroyed by the application.
The released method would be called through C++ and the scripting machine wouldn't have a clue that it happened. Would it?
The released method would be called through C++ and the scripting machine wouldn't have a clue that it happened. Would it?
Quote:Original post by andrew1b
Thanks, I read that. I just can't see how even with a reference counter the scripting machine would know when an instance created in the application was destroyed by the application.
The released method would be called through C++ and the scripting machine wouldn't have a clue that it happened. Would it?
It doesn't need to have a clue. If the C++ program holds a reference and the script holds a reference, then the reference count is 2. If the C++ program releases its reference, then the reference count is decremented to 1. Only when the reference count is decremented to 0 (meaning no one holds a reference) is the pointer deleted.
Quote:Original post by Halifax2Quote:Original post by andrew1b
Thanks, I read that. I just can't see how even with a reference counter the scripting machine would know when an instance created in the application was destroyed by the application.
The released method would be called through C++ and the scripting machine wouldn't have a clue that it happened. Would it?
It doesn't need to have a clue. If the C++ program holds a reference and the script holds a reference, then the reference count is 2. If the C++ program releases its reference, then the reference count is decremented to 1. Only when the reference count is decremented to 0 (meaning no one holds a reference) is the pointer deleted.
What if I want to delete the object for good? The way you pointed, the handle would still be valid to the script.
What I want is to erase the instance from the STL list it’s in, and automatically invalidate its handle in the script. Is there such a thing?
This is possible, but it's a bad idea. However, if you really want to do it, there are a few different ways to go about it. One way would be to use boost::shared_ptr<>s to the object in the C++ portion of the application and bind boost::weak_ptr<> as a value type in AngelScript. Instead of registering member functions to your class directly, you can register proxy functions that lock the pointer and forward the arguments to the locked object.
what if I have an object that is already reference counted (in C++). can I use the same reference-count-variable for the script?
Register it as a reference type and just use the asBEHAVE_ADDREF and asBEHAVE_RELEASE behaviors.
Quote:Original post by SiCrane
This is possible, but it's a bad idea. However, if you really want to do it, there are a few different ways to go about it. One way would be to use boost::shared_ptr<>s to the object in the C++ portion of the application and bind boost::weak_ptr<> as a value type in AngelScript. Instead of registering member functions to your class directly, you can register proxy functions that lock the pointer and forward the arguments to the locked object.
Sorry for the double post, but why is it a bad idea? Using weak_ptr<>s for the reference objects sounds fine.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement