Advertisement

Handle to value type

Started by July 17, 2019 08:10 AM
5 comments, last by _Vicious_ 5 years, 4 months ago

Hi,

thanks for all the hard work you've done on AngelScript over the years!

Is it possible to pass around references to application-registered value types in AngelScript? For typical use case I'm returning a reference to such type and that works fine but there are also cases where I would like to be able to return a handle or a null. For such handles, the memory management is taken care of by the application.

Thanks in advance!

 

No. Handles for value types is not allowed. This is because the handle potentially has a longer life time than the object. And since the value type won't be kept alive by the existence of the handle referring to it, this may lead to the handle referring to invalid memory, and potentially crash your application if accessed inappropriately.

Are you sure the object really should be registered as a value type? It sounds like you want it to behave as a reference type, so why not register it as a reference type?

 

 

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

Advertisement

Well, the first and foremost - for simplicity's sake. I didn't really want to bother myself with coding the reference counting machinery because objects of this particular POD type aren't created via the factory pattern. They are either attached to game entities, which are pool-allocated and have infinite lifetime or are temporary stack objects used to pass the entity state around.

Please correct me if I'm wrong but it just occurred to me that what I had described above sounds like a potential use-case for asOBJ_NOCOUNT handle types but not quite, as I would still like AS to perform the reference counting on script objects.

Yes. asOBJ_NOCOUNT will allow you register reference types without having to bother with implementing reference counting. It works well for cases like you mentioned where the object instance has infinite lifetime.

However, it appears you use two distinct memory models for the same type. You don't want to allow handles to the instances that are supposed to be temporary stack objects, as the handle might stay alive longer than the object on the stack. And you don't want to use instances from the memory pool as temporary stack objects as it would be difficult to know when the pooled instance can be reused.

To solve this you could register the type twice with different names. Once for the pool allocated model as asOBJ_REF|asOBJ_NOCOUNT, and another for the temporary stack objects as asOBJ_VALUE|asOBJ_POD. Then add implicit conversions between the two so that it when passing the objects around by value they can be interchanged transparently.

 

 

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

Thanks for your suggestion but the idea of having two identical classes felt somewhat clumsy. I ended up converting the class to use reference counting, which is only performed for script-allocated objects, looked up via std::map with pointer as the key. This incurs performance penalty but hopefully it's going to be negligible .

This topic is closed to new replies.

Advertisement