Arrays in Generic class

Question

Is there any disadvantages in using array in generic class? If yes, what are they? If No what are the advantages?

Answer 1

Read this:
What is cool about generics, why use them?

Answer 2

Performance wise is the boxing and unboxing of objects. Ie the overhead of casting objects back to its original type.

Readability wise, if you specify the type in the collection it makes the code more readable.

Answer 3

The main advantage I can think of for using arrays in generic classes is to avoid boxing. Specifically, when you cast a value type (a "primitive" such as Int32, Boolean, etc.) to an object, the runtime has to wrap the value type instance in a reference type ("box" it) and place it on the managed heap. That makes accessing value types as reference types much less efficient than accessing them directly as value types.

If you have a

class MyGenericContainer<T>
{
    private T[] array;
}

and you instantiate MyGenericContainer<int>, you'll get an array of int instances, which won't be boxed when you access them.

On the other hand, if you had

class MyContainer
{
    private object[] array;
}

even though you can certainly add an integer to the array, it would be boxed, and therefore access to it will be less efficient, and the act of storing it involves more storage. To be specific, each array will store a reference (4 bytes?) to its item. In the generic case when parameterized with a value type, the pointer will point to a value type that exists as a field within the parent object on the managed heap. In the non-generic case, the pointer will reference an object wrapper within the parent object on the managed heap, which will internally reference the value type instance somewhere else on the heap. So, you get the overhead of an additional object and reference when boxing value types. Accesses also involve more overhead, but it's complicated depending on the particular use case.

Answer 4

o.k.w., Simply put, Generics are faster and give you a much more flexible approach to working with a strongly typed language such as C# . You are giving the compiler a compile time size hint (it won't have to discover it during run-time) that it is to contain some class 'T' List. But this just the beginning . . you can have generic classes and methods . . . you can limit the type by using the where statement. Here's an example (no, I didn't compile it . . it won't compile . . this is strictly for demo purposes only) sorry if it's real clear . . .it's getting past my bedtime!

Called like:

CoolOps op = new CoolOp();

   IOtherCoolInterace oci = DoThisVeryCoolThing<IOtherCoolInterace,CoolOps>(op);

public T DoThisVeryCoolThing<T,U>(U whatIAm) where U: IMyVeryCoolInterface where T: IOtherCoolInterface  // I'm restricting the type that can be operated on and returned
{
    T thingToReturn  = default(T);

    if(whatIAm == null) return thingToReturn;

    try
    {
        thingsToReturn = whatIAm.DoSomeWorkOnTheInterface(); 

    }
    catch(Exception ex) { ... // do exception stuff here }

    return thingToReturn;  // return work done
}

public interface IMyVeryCoolInterface
{
    IOtherCoolInterface DoSomeWorkOnTheInterface();
    . . .
}

// My operation must implement this interace
public class CoolOps : IMyVeryCoolInterface
{
     . . . 
   IOtherCoolInteface DoSomeWorkOntheInterface()
   {
      return xxx;
   }
}

etc etc...

What this does it to do some work on an instance of U that must implement an interface (my contract!) IMyVeryCoolInterface and that interface contains a method call that returns an object instance that must implment IOtherCoolInterface.
How does this work in the real world? This lets you set up a general approach to doing work with many different types. So, if you had a number of classes that described opertions, work on those operations can be called in a 'generic' fashion as above. This avoids repetitive mistake prone code where similar methods are written over and over again that do only a very slightly different operation based on a type(different algorithms for an image blur for example) - but just in slightly different fashion. e.g. ** We know we are going to do an image operation on an image but lets parametrize the image type (jpeg,png, etc) and algorithm (5x5, 3x3 convolution etc) and write the method once ** Or something to that effect . . .

I hope this helps . . .

TheEruditeTroglodyte

Answer 5

There is nothing special about using arrays in generic vs using them in any other non generic classes. The pros (memory take, direct access by index, etc) and the cons (insertion price, growth price) are the same.

Internally the CLR transforms any generic into a concrete type representation so about using generic arrays there's no difference vs standar typed arrays.