I have a slight problem which I have a solution to but want to check to see if I need to do it.

I have a structure that inherits from another structure and I need the cast ability in angel script to typecast the inherited object to the base class.
However this requires the object to be a reference however I would rather the object be of value type since its only a structure to send to a function to create another object.

If i created the class with no ref counter I take I would have to delete the object within C++ and ensure the angel script object/s is also cleaned up as well.

I can still inherit and add a ref counter but I would rather not have to do this.

With asOBJ_NOCOUNT you're telling AngelScript the objects of the type will be allocated on the heap just like any other reference type but that AngelScript doesn't need to increment and decrement the references. All the rules that apply to asOBJ_REF are also valid for asOBJ_REF with asOBJ_NOCOUNT so they will allow the ref cast behaviour.

Of course without the reference counting you'll be responsible for identifying when no more references to the object exists and the memory can be released.

with ref counting the object OBJA will have a ref count of 2. If I was to make OBJA NULL I take it the ref count of the object will go down to 1 and OBJB will still be valid until it comes out of scope or is equal to NULL?

If I didnt use ref counting and I made OBJA NULL does OBJB still exist and I would have to explicitly make it equal to NULL to also remove it even if OBJB went out of scope.

Sorry if this is all a bit basic I have a rough understanding of it but I just want to make sure im not doing anything that will cause memory leaks and corruptions.

obj() creates the object instance that is allocated somewhere on the heap.

OBJA and OBJB are both handles that refer to the same object instance. And as long as there are any references the object instance should not be destroyed and deallocated, or you'll end up with what's often called "dangling pointers". Access to an invalid object through such dangling pointers can cause unexpected behaviour, in the best case it will immediately crash the application, but in a worst case it will cause less noticeable bugs that can be very difficult to find.

With reference counting the obj knows exactly how many handles are referring to it, and can thus easily know when it is safe to destroy and deallocate the object.

Without reference counting you'll have a difficult time to know how many handles there are. But with careful design of your application you'll be able know when it is not possible to exist any handles, and the object can be destroyed, e.g if there are no active script contexts and there are no global variables in the scripts you know that the script can't hold any references to the object.

The first alternative is probably more performatic, but has the drawback that you're actually using a different object type than the true type. In many cases this will not be a problem, but in others you'll need to wrap your application functions to translate the real object into the wrapper object so it will have the reference counter.

The second alternative should work pretty seamlessly, though the performance might suffer somewhat if you have a lot of operations on this object as the look-up into the map will add significant overhead.

You need to make sure the object is added to the map with the factory function, i.e. when the factory function returns the handle the refCount should be at least 1 (it can be higher if you're storing the handle elsewhere too).