For type safety and avoidance of boxing, your only option is a specific overload for input of type int
:
public void AttachInput(int input)
{
Inputs.Add(input);
}
Update:
The OP has updated the question with a theory:
Taking a deeper look in generics, it
seems to me that Convert.ToInt32 when
T is already an int does no boxing to
an object and its int overload is the
one being called.
This is not right, and a simple test can demonstrate it. Suppose we write our own set of overloads just to detect which one is being called:
public static class OverloadTest
{
public static void Foo(int x)
{
Console.WriteLine("Foo(int)");
}
public static void Foo(bool x)
{
Console.WriteLine("Foo(bool)");
}
public static void Foo(object x)
{
Console.WriteLine("Foo(object)");
}
}
Now we write a generic method to model the one in the question:
static void CallTheRightFoo<T>(T value) where T : struct
{
OverloadTest.Foo(value);
}
The theory is that because the CLR/JIT will produce a specific version of the method for each value type, it can pick the specific overload for int
as one is available.
So here's the test:
struct Test { } // in order to test a user-defined value type
static void Main(string[] args)
{
CallTheRightFoo(1);
CallTheRightFoo(true);
CallTheRightFoo(new Test());
}
The output is:
Foo(object)
Foo(object)
Foo(object)
To relate this to Convert.ToInt32
, from your generic code you will always be calling the overload that accepts object
, and so the value will have been boxed and must then be unboxed inside Convert.ToInt32
(which also has to check what type it is first).
Although to reiterate an important point behind all this: although boxing/unboxing is more expensive compared with not doing it, it is quite possibly of negligible cost compared with any actual work your code is doing. So I wouldn't worry too much about the cost of it until you can prove that it is a genuine burden on a realistic model of an application using your library.