koobas.hobune.stream
The question is answered, right answer was accepted
Object to Foo is okay, but Object[] to Foo[] gives error.
Hey guys, this one is quite strange and I can't any info about this, or I'm searching for the wrong terms.
Basically I'm trying to build a reference manager that stores arrays of type Object[] (so that I can store multiple arrays of different types, of course not multiple types within one Object[])
Here is the code, and the error "InvalidCastException: Cannot cast from source type to destination type." occurs on the last line of the Start function, but the middle one is okay.
public class Foo : MonoBehaviour
{
private void Start()
{
//create a one-length array containing myself.
UnityEngine.Object[] test = new UnityEngine.Object[] { this };
Foo fooTest = (Foo)test[0]; //casting one object is okay.
Foo[] fooArray = (Foo[])test; //casting Object array as Foo array is bad.
}
}
I'd like to note that using the following doesn't give an error, but the array is still null.
Foo[] fooArray = test as Foo[];
The only way around this that I can think of, is to create a Foo array at the size of the Object array, and loop through each element casting them every time (While this method works, I feel like it's a ridiculous work-around).
If you're sure that each Object in test is a Foo, why not create a Foo array from the beginning?
I feel I should add here that the "as" semantics (such as`test as Foo[]`) is defined to be a cast that returns null if the cast fails, rather than throwing an error.
Try using Linq:
Foo[] fooArray = Array.ConvertAll(test, item => (Foo)item);
you will have to add using System; and using System.Linq;
Works nicely, and much better than writing a loop. Thanks fafase.
Essentially, the Linq result does just loop through and copy the array, but it does so in a shorter line of code, and possibly one that is optimised at the bytecode level, making it potentially faster than writing the same procedure in the native language.
Actually Linq is slower, that is why it should not be used in Update. http://www.schnieds.com/2009/03/linq-vs-foreach-vs-for-loop-performance.html This is probably due to the added code in the Linq version to be abe to work on any case while your own foreach loop is doing only what you want to.
Probably true, actually. Linq does have to deal with a more general case (for example, in this case, invoking a function to do the cast, rather than doing it directly), which will hamper performance slightly. There are some Linq functions, though, which are optimised at bytecode level, though they tend to be the simpler ones, which don't need extra arguments to specify your specific case (i.e. ones that don't require invoking a delegate function).
Thanks for the specification/clear up. I guess I'll write my own (static?) for-loop to deal with this specific case.
