We’ve seen how to create powerful, Burst-compatible generic algorithms already, but today we’ll take another approach to generic algorithms and implement them in the style of C#’s LINQ. Along the way, we’ll tackle a new challenge by implementing a generic algorithm that allocates a new collection.
Posts Tagged generic
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!
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<T>, classes like
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.