So far we’ve had C++ classes that derive from other classes, but not their interfaces. Today we’ll make C++ classes implement all their interfaces to form a full type hierarchy. Along the way we’ll learn about how inheritance works in C++, specifically the esoteric form known as “virtual inheritance.”
Posts Tagged interface
Now that we have complete support overriding everything—methods, properties, indexers, events—that can be overridden in a base class or interface, there’s a bit of tidying up to do. In today’s article, we’ll take steps to make base types much more useful by inserting them into their proper place in the type hierarchy.
Today we’ll complete our ability to use C++ classes to derive from C# classes and implement C# interfaces. So far we’ve been able to override methods, properties, and indexers. Today we’ll add the ability to override events and derive from classes that don’t have a default constructor.
Those are the last two pieces of the puzzle that will allow us to derive from any C# base type with a C++ class. Read on for all the details about how this works.
Implementing interfaces and deriving from classes is commonplace in many codebases. Today we’ll make it so C++ classes can implement C# interfaces and derive from C# classes. This means our C++ game code will be able to implement custom
IComparer classes for sorting a
List and derive custom
EventArgs for dispatching in events. Read on to see how this is implemented and how to use it in our projects.
Closures allow you to save the local variables of a function and access them later in a callback. Think of how lambdas can access the local variables of the function they’re declared in, even though the lambda itself is another function. Unfortunately, creating a lambda like this creates garbage for the GC to collect and you have no control over that process. Today’s article introduces an alternative that allows you to take control over the GC and still use nice, type-safe closures. Read on to learn how!
Last week’s article showed a technique that you can use to abstract the Unity engine so that you can test code that uses it. Today’s article presents another technique that allows you to remove this abstraction layer so your game code is faster and more natural. Read on to learn how!
How do you write unit tests for code that uses the Unity engine to play sounds, make web calls, or render graphics? Today’s article shows one solution!
There’s no question that the
for loop is a good idea, but events are much more complex. They’re enshrined into C# by the
event keyword, but not everything about them is good. Today’s article shows some considerations you should take into account when deciding whether or not to use an event. Bonus: it includes some little extension methods to make using events and delegates easier!
Last year I introduced a Unity-based model-view-controller (MVC) design pattern and in the many comments on that article, a theme arose. The “model” part of MVC is arguably not necessary since Unity stores so much of the data itself. Today’s article takes that theme and elaborates on it to create and introduce a new Unity-specific design pattern. Read on to see how this adaptation of MVC works!
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!