Sign in to follow this  
iraxef

Is per-ref-object user data possible?

Recommended Posts

Am I correct in assuming that the asIObjectType user data is per-type and not per-object? Is it possible to somehow register per-object user data?

 

I register all my application (ref) types as nocount ones like so:

 

RegisterObjectType("MyObj", 0, asOBJ_REF | asOBJ_NOCOUNT);

 

Sometimes users run into object lifetime issues where the underlying C++ object (e.g. a MyObj instance) has gone away, but a script is still holding on to a handle to it and attempting to call (C++) member functions through that (now-stale) pointer crashes the application. If I had some way to append a user data to every instance of a script handle to an application-registered ref object.. I might be able to do some debug checking to ensure that the handle isn't a stale one.

 

Have you heard of any users doing something similar? Do you have any suggestions for managing object lifetimes when the ref types can't be reference counted?

 

Thank you very much.

Share this post


Link to post
Share on other sites

For the lifetime issues, check the weak reference functionality and the weakref add-on. These allow you to implement a shared flag which tells if the object has already been destroyed. The example in the first link describes a normal reference counted object, but I'd believe (not 100% sure though) the concept should also be possible for NOCOUNT objects.

 

http://www.angelcode.com/angelscript/sdk/docs/manual/doc_adv_weakref.html

http://www.angelcode.com/angelscript/sdk/docs/manual/doc_addon_weakref.html

Share this post


Link to post
Share on other sites

asOBJ_NOCOUNT is difficult to use for objects that do not have a very precisely known lifetime, for the very reason that you discovered.

 

Adding user data to handles is not supported in AngelScript. But, you could register the type without the asOBJ_NOCOUNT and register the asBEHAVE_ADDREF and asBEHAVE_RELEASE behaviours as global functions (with asOBJ_CDECL_OBJLAST). These functions could then store a ref count in a map where the object pointer is the key.

 

 

Share this post


Link to post
Share on other sites

Wouldn't removing asOBJ_NOCOUNT allow script to attempt to instantiate these objects? I'd need to prohibit that - these objects already exist and I just want script to be able to manipulate them. Also, by storing the refcount per object pointer, I'd have no way of knowing that C++ (outside the script) destroyed the object. The only thing I can think to do with the global map is to assert (when C++ is attempting to destroy the object) that the object's pointer isn't in the map.. as a means of warning the user that they have an object lifetime problem. Is that what you were thinking?

 

Thanks

Share this post


Link to post
Share on other sites

No. AngelScript will only be able to instantiate the objects if you provide the factory functions for that (asBEHAVE_FACTORY). 

 

You're correct, having the asBEHAVE_ADDREF/RELEASE behaviors will not prevent C++ from destroying the object from the application side. It will only allow AngelScript to tell the application how many references that the script engine still holds to the object so that you will have a chance of avoiding the destruction of the object from the application side until all references from AngelScript are released.

 

If you really cannot control the lifetime of the objects in the application, i.e. not destroying them, then you should probably avoid exposing the objects to the script all together, and instead have the scripts work through an abstraction layer (i.e. wrappers) where the abstraction layer can verify if the object is still alive before attempting to access it.

Share this post


Link to post
Share on other sites

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