Sign in to follow this  

Shared-pointer-like behavior

This topic is 2856 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by Halifax2
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.


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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Basically, AngelScript bends over backwards so that you can always treat objects as valid, so if you introduce types that can be deleted from under the script's nose then you're throwing away some of the advantages of using AngelScript. And since this isn't the normal state of affairs for AngelScript objects, the language doesn't have all the features that you might want in order to deal with it.

Share this post


Link to post
Share on other sites

This topic is 2856 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this