Now that we’ve seen how types are implicitly converted in C++, we can see how they’re explicitly converted by casting. C++ offers a lot more kinds of casts than C# to control the conversion process. One of them—dynamic_cast—introduces the concept of Run-Time Type Information or RTTI, so we’ll go into that today as well.
Posts Tagged exception
Like C#, C++ also uses exceptions as one of its main error-handling mechanisms. Today we’ll learn all about them: throwing, catching, their impact on destructors, what happens when they go uncaught, and so much more.
IDisposable is becoming more and more prevalent in Unity. Previously, it was typically only used for I/O types like FileStream. Now it’s used for in-memory types like NativeArray<T> to avoid the garbage collector. Needing to call Dispose manually means we’re explicitly managing memory, just like we’d do in lower-level languages like C++. That comes with some challenges, especially with shared ownership, which we’ll deal with today.
A couple years ago, I wrote an article showing how to empower game designers with the ability to write simple formulas like PlayerLevel*100+100. These are much more useful than just constants and don’t require any of the complexity of a real programming language. Today we’ll bring it into the Burst-compatible world and also improve its ability to handle more complex formulas.
Assertions are an incredibly handy tool, but do they work in Burst-compiled jobs? Today we’ll find out!
Unity’s Burst compiler imposes an interesting subset of C#. The “no managed objects” rule of thumb is not always correct. Today we’ll look at eExceptions, which are managed objects but are partially supported by Burst. What’s allowed and what’s banned? Read on to find out.
Some errors can be handled and some cannot. Nevertheless, it’s extremely common to see codebases chock-full of ineffective error handling for these unrecoverable issues. The result is a lot of extra code to write, maintain, and test that often serves to make debugging harder. Today’s article shows you how to make debugging internal errors so much easier by effectively writing code to handle them.
Unity 2018.1 was released last week and with it comes support for C# 6. Today we’ll take a look at the C++ that IL2CPP generates when we use the new features in C# 6. Warning: one of them is buggy and shouldn’t be used.
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.
Like them or not, exceptions are the standard way of handling programming errors in C#. We need to be able to catch C# exceptions in our C++ code so we can gracefully recover from them. Likewise, we need uncaught C++ exceptions to behave like unhandled C# exceptions: display an error and move on instead of crashing. Today’s article continues the series by implementing both those features in the GitHub project and explaining how that implementation was done.