Mastering C# and Unity3D

C++ Scripting: Part 15 – Delegates

This week’s article adds another major feature to the C++ scripting system: delegates. These are vital so C++ game code can use features like Unity’s UI system (a.k.a. UGUI). Without them, we wouldn’t be able to handle button clicks or other UI events. So read on to learn how these were implemented in the GitHub project.

This JSON snippet says to generate code so C++ can use either Action<float, float> or Action<int, double>.

The last bit of JSON config is to specify the maximum number of simultaneous delegates that C++ can use at once. By default, it’ll use whatever we pass to Bindings.Init at runtime. If we want to override this, we can do so at two levels:

MaxSimultaneous in the outer block says that we want a maximum of 100 Action<T1, T2> types at once. Then MaxSimultaneous in the GenericParams block says that we want a maximum of 500 Action<float, float> types at once. The GenericParams for Action<int, double> doesn’t specify MaxSimultaneous, so it inherits the default for Action<T1, T2>: 100.

That’s all there is to configuring the code generator. Now let’s look at how to use the generated code.

There are no global functions in C#, so a class is required to hold them. That means that the compiler will create a class for us when we create a delegate from a lambda or anonymous method. It looks something like this:

This is also how “closures” work. Our lambda can access the local variables of the function because they’re copied into fields of the class that the compiler generates.

In C++, we’ll skip the syntax sugar for lambdas and anonymous functions for now and just create a class in the first place. First, the code generator will create a class like this:

// The number (2) is the number of type/generic parameterstemplate<>struct Action2<float, float>: Object
{// Constructor. Creates the Action<float, float> in C#.
Action2();// Invoke the Action<float, float> in C#void Invoke(float arg1, float arg2);// Called when the Action<float, float> is invoked in C#virtualvoid operator()(float arg1, float arg2);// Add and remove delegates to this delegatevoid operator+=(System::Action2<float, float>& del);void operator-=(System::Action2<float, float>& del);};

This class is pretty useless by itself. If we create one, we’ll have an Action<float, float> that does nothing when invoked. To make it useful, we need to derive from it and override the operator() to do something useful.

This all works very much like how delegates work behind the scenes in C#. One key difference is that we have direct access to the delegate class rather than having it hidden from us. This allows us to add whatever fields and functions we want to the delegate class instead of being limited to just Invoke.

On the downside, we’ve given up some syntax sugar. We have to type a lot more code to make quick delegates compared to the minimal syntax that lambdas require. We can work around that, though. C++ also includes support for lambdas, so all we need to do is create a delegate class that contains one and call that from operator().

Here’s the delegate class we’ll create:

// The first two paramters are the type parameters to Action// The third parameter is the type of object to call from operator()template<typename T1, typename T2, typename Callable>struct CallableAction2 : Action2<T1, T2>{// Hold the thing to call
Callable func;// Constructor requires something to call
CallableAction2(Callable& func): func(func){}// Instead of doing anything here, call the thing to call and forward the// parameters on to itvoid operator()(T1 arg1, T2 arg2)override{
func(arg1, arg2);}};

Now we don’t need to create any delegate classes if we don’t want to. Instead, we can just use MakeAction2 and pass in whatever we want to be invoked. A future version of the code generator will create these wrapper classes and functions for us, but for now we can do it manually as above.

We also have overloaded += and -= operators on all delegate types. These work just like in C#:

// Create two delegates
SetXYDelegate del1;
del1.transform= go1.GetTransform();
SetXYDelegate del2;
del2.transform= go2.GetTransform();// Add the second delegate to the first
del1 += del2;// Invoke the first. The second will also be invoked.
del1.Invoke(10, 20);// Remove the second delegate from the first
del1 -= del2;// Invoke the first. The second won't be invoked.
del1.Invoke(30, 40);

Finally for usage, delegates can have return values. This also works as it does in C#:

Returning values from delegates can be useful when using functions like Array.Sort which takes a Comparison delegate. That delegate is called with two elements of the array and returns an int indicating their sort order.

Note that we’re able to call both Invoke and operator() from C++ code. This gives us the flexibility to use two different behaviors. Calling Invoke is just like invoking the delegate in C# and will cause its C# counterpart to be invoked as normal. This may have side-effects on the C# side, including calling delegates that were added to the delegate. However, we can also directly call operator() on a C++ delegate to invoke it alone. No added delegates will be invoked and no calls will be made into C#. This makes those calls faster than Invoke and provides a nice, lightweight option to a full Invoke call. To call this way, simply call the delegate like a function: del(2, 3).

Implementing delegates in the code generator relies on a combination of techniques from previous articles in this series plus a few extra tricks. Calling from C++ into C# for construction, destruction, Invoke, operator+=, and operator-= is all just like with any other function call into C#. Calling from C# into C++ when the delegate is invoked is just like when a MonoBehaviour “message” like Update is called. However, there are some critical extra steps to consider in both languages to make this work.

When a delegate is invoked, C# needs to tell C++ which delegate was invoked. That’s just like how C++ needs to tell C# which object to call a method on. Again, we’ll use handles to solve this problem. Instead of object handles stored on the C# side, we’ll store delegate handles on the C++ side. These allow C# to reference a delegate by an int and C++ to look up a pointer to that delegate using that int. This is why we added the MaxSimultaneous properties to JSON: we need to know how many delegate handles to store.

Next, we need to coordinate the lifecycles of C# and C++ objects. When a delegate class is instantiated on the C++ side, it’ll instantiate a delegate on the C# side. The delegate may be passed around and referenced by various other C# objects, such as by setting one to a property of a long-lived object. If the C++ delegate object destructs, its handle becomes invalid. If the delegate is invoked, C# will call into C++ with the invalid handle of a dead C++ delegate and a crash will likely result.

To work around this, we need a couple of things. First, we need a way for C++ to tell C# that a delegate handle is no longer valid and it shouldn’t ever be called again when the delegate is invoked. That can be easily slotted into the C++ class’ destructor. Second, we need a way to flag a C# delegate so that it’s no longer invoked. Unfortunately, unlike in C++, we don’t have access to the fields, properties, and methods of a C# delegate other than basic functions like Invoke. To work around this, we create a class to contain the delegate and the delegate handle:

class SystemAction
{// Delegate handle from C++publicint CppHandle;// The C# delegatepublicSystem.ActionDelegate;// Construct with the handlepublic SystemAction(int cppHandle){
CppHandle = cppHandle;// Create the delegate// This is implicitly like "new System.Action(Invoke)"Delegate= Invoke;}// Delegate functionpublicvoid Invoke(){// If the handle is still valid, we can call C++if(CppHandle !=0){
SystemActionCppInvoke(CppHandle);}}}

Having this class means that we can later set CppHandle to 0 when the C++ class destructs. Even though the C# delegate lives on because C++ code never removed all references to it, C++ code won’t be called when the delegate is invoked due to the if (CppHandle != 0) check.

With the addition of these two techniques—C++ delegate handles and C# delegate classes—we can now safely use delegates from C++ without worrying about lifecycle issues.

In the miscellelaneous category, Unity 2017.2 was released this week. One of the changes split the Unity API from one assembly (UnityEngine.dll) into a whole bunch of “module” DLLs. This means that different types in the Unity API are now in different assemblies. That, in turn, impacts the code generator because it looks up string type names from the JSON config file using Assembly.GetType. This wasn’t a critical problem as we could always specify more DLLs in the JSON config file by adding UNITY_DLLS/UnityEngine.AudioModule.dll, for example, but that’s quite inconvenient. Instead, the code generator has been upgraded to automatically provide access to all 36 non-obsolete Unity modules. Only the “legacy particles” module is omitted since it’s been obsolete since Unity 4.0 and causes a compiler warning. To get access to it, add UNITY_DLLS/UnityEngine.ParticlesLegacyModule.dll to the JSON. Unity versions prior to 2017.2 are still supported via a #if check.

That’s all for today. Next week we’ll continue by making delegates much more useful by supporting events. In the meantime, check out the GitHub project for all the nitty-gritty details about how delegates were implemented or just to try it out.

Questions about the project? Want to provide feedback? Leave a comment to let me know.