Iterators aren’t magic. We’ve seen the IL2CPP output for them and it’s not complex. It turns out we can just as easily implement our own iterators and gain some nice advantages along the way. Read on to learn how!
Posts Tagged iterator
NativeArray<T> is great, but very limited in functionality. We can fix this surprisingly easily! Today we revive a two year old series that created the iterator project. Iterators are like a no-GC version of
IEnumerable<T> and LINQ which have a lot of power but only support managed arrays (
List<T>. Today we’ll add support for
NativeArray<T> and inherit support for the same functionality. We’ll also spruce up the project with proper unit tests, assembly definitions, and runtime tests to confirm that zero garbage is created. Read on to see how this was done and how to use iterators with
Today we’ll look at the C++ code that IL2CPP outputs when we use iterator functions (those that
switch statements, and
using blocks. What are you really telling the computer to do when you use these C# features? Read on to find out.
(Website Announcement: check out the new tags page to find articles by topic)
Unity code frequently makes use of the coroutine feature of
MonoBehaviour. It can make asynchronous code a lot easier to write, but runs into problems when exceptions are thrown. There’s no avoiding exceptions since they’re built into C# (e.g.
NullReferenceException) but we can cope with them, even when they’re in coroutines. Today’s article introduces a helper function or two that you can drop into your projects to help you handle exceptions thrown from your coroutines. Read on to learn how!
In asynchronous programming we’re constantly dealing with callback functions. Maybe you have to call some function in a third party library that takes a callback function. Regardless, Unity programmers often want to use coroutines for their asynchronous tasks. Today’s article show you how you can use callback-based code from your coroutines, all while being simple and easy to use. Read on to learn how!
Iterator functions and their ability to
yield return values then continue on really come in handy for a variety of situations. Unfortunately, they come with some pretty serious performance and garbage creation drawbacks. So today’s article explores alternatives in various forms of callbacks: delegates, interfaces, and classes. Can they perform better than iterator functions? Can they avoid garbage creation? Read on to find out!
Callbacks are a mainstay of the real-time games and apps we build in Unity. We’re constantly writing asynchronous code for every operation from walking a character to a destination to making a web call. It’s really convenient for these functions to “call back” and report their status so we know how the operation is going. Unfortunately there are also a lot of dangers that come along with this. Today we’ll look into the surprisingly large number of ways you can “call back” in C# and some of the ways you can get burned doing so.
We’re nearing the end of the series to build a no-garbage replacement for
System.Linq. Today we tackle functions that work on already-sorted ranges and functions that work on ranges that are in heap order. These include common set operations like “union” and “intersection”. Read on to see how to use them and for the updated library that you can use to eliminate your garbage creation!