For my scripted entity-component handling system I need to map from a script object to the C++ side "parent object" or container for that script object. Previously I used a separate associative array for this, but then it occurred to me that storing the C++ object pointer directly in the asIScriptObject as userdata would accomplish the same thing without needing the associative array.

Therefore, I customized "my" asIScriptObject to support userdata.

Would this be a good core feature for AngelScript itself? asIScriptContext, Module & Engine already have userdata as well.

This would imply an additional memory usage for everyone, regardless of the user data being used or not. I have user data in the context, module, engine, and object type, already but it's not really meant to exist that many individual instances of those. There can be quite a lot of script objects on the other hand, depending on what the scripts are used for.

Is there a particular reason why you don't make the information you want to store as user data a declared property in the script class? That way you would only add the extra memory usage where it is actually needed.

Yes, alternatively I could use a mandatory base class for all script objects that participate in the entity-component system. That base class would then do all the C++ parent/proxy object related bookkeeping. How would you recommend to do this? Would I compile an internal, always-available script module which declares the base class as shared?

There are so many ways of doing it. Which way is best depends a lot on what you plan to do with the connection.

One way is how I do it the 'game' sample in the SDK. There I simply pass the handle to the C++ object in the script class constructor, making it the responsibility of the script to store the handle as a member.

If you want to use a shared base class, then you can add its declaration as a predefined script section from the application to all modules where you expect it to be used. The compiler will detect that it is shared and reuse the same code for the base class.


The way I do it in the 'game' sample, is effective and simple, but it doesn't hide the fact that the entity is really two separate objects, i.e. the C++ object + the script object. With the shared base class you'll be able to hide most of that lower details of the implementation from the script writer. On the other hand, you might end up adding undesired overhead, for example if the base class implements methods to work with the C++ object which could be done directly from the script.


As always, it is a balancing act. You'll have to weigh the benefits against the drawbacks and determine what suits you the best.