We looked at some generic algorithm examples in the previous article, but they weren’t very generic in one respect: they all required a NativeArray<T>. What if we wanted to make them more generic so they could work on any type of collection? Today’s article shows two ways to do just that!
Posts Tagged generic
There are many common algorithms that we use constantly: searching, filtering, mapping, and so forth. Today we’ll write a few in the Burst-friendly way as examples of how to write Burst-friendly code that’s still reusable and efficient.
Many algorithms get used over and over: searching, sorting, filtering, etc. C# makes these available with LINQ and functions like Array.Sort, but these can’t be compiled by Burst because interfaces and delegates aren’t supported. So how do we implement these generic algorithms to avoid re-writing them over and over? Today we’ll explore one technique to solve this problem. Read on to learn how!
Today we’ll make a new type that addresses some of the deficiencies in Nullable<T>. We’ll end up with a good tool for dealing with operations that may or may not produce a result or take a parameter, even in Burst-compiled code. Read on to see how it works!
About a year ago we saw how easy it is to use code generation to go beyond the limits of C# generics. The system we used simply replaced strings in a template file to generate a C# file. Today we’ll go way further and radically increase the power of the code generator by using some simple, off-the-shelf tools.
A lot of powerful language features like LINQ require massive performance hits, but today we’ll discuss some easy, low-overhead ways to add some safety and usability to C#.
C# allows for overloading not just function names, but also type names. This is used throughout the .NET and Unity APIs for interfaces like IEnumerable and IEnumerable<T>, classes like UnityEvent<T0> and UnityEvent<T0, T1>, and delegates like Action<T1, T2> and Action<T1, T2, T3>. C++, however, does not support type overloading. Today’s article explores how to deal with this and, once we’ve solved the issue, what extra C# features we’ll have access to in C++.
Since their introduction in part 7, support for C++ MonoBehaviour messages has always been a special case. The reason for this was that we didn’t have good enough support for what I’m calling “factory functions.” These are functions like GameObject.AddComponent<T> that instantiate a generic type. This week we’ll go over why that support was lacking, what was done to fix it, and how the new system works.
The story usually has three parts. First, find the highest CPU cost functions in a profiler. Second, look at the corresponding C++ code that IL2CPP generated from C#. Third, stop using more parts of C#. Today’s article explores some more IL2CPP output and discovers some more areas of C# that are shockingly expensive to use.
C# APIs are chock-full of generics. Generic types, generic method parameters, generic return types, generic fields, generic properties, deriving from generic types, and generic constructors. We can find all of these in the Unity and .NET APIs. Some are more frequent than others, but we’re going to need support for all of them to make C++ scripting a viable alternative to C#. Today’s article continues the series by adding just that: support for all of these kinds of generics. Let’s dive into how to use them as well as some bonus items added to the project this week.