Cast value type to generic

Question

I have a generic class that I need to constrain to only value types (int, float, etc.). I have a method that calls the Parse method based on a test of the type. For example:

class MyClass<T>
{
    ...

    private static T ParseEntry(string entry)
    {
        if(typeof(T) == typeof(float))
        {
            return (T) float.Parse(entry);
        }

        if(typeof(T) == typeof(int))
        {
            .... you get the idea
        }
    }
}

Constraining T to struct doesn't work and I really want to avoid boxing/unboxing if possible. Any ideas?

EDIT: To give a little more insight into this. I noticed in a library I'm developing that two classes had very similar properties/methods etc. the only difference was the underlying type of data (int or float). THis lead me to a design with generics. The only hangup is because of the call to the specific Parse method depending on if it's a float or int. I could get around it with boxing/unboxing but I really wanted to avoid that if possible.

Answer 1

Unfortunately, you cannot create constraints of the type of describe. You cannot write, for example:

class MyClass<T> where T : int { ... } // won't compile

You may be better off leaving the constraint to be struct, but add some runtime checks to make sure that T is only one of the supported types when you instantiate the class. Since you haven't said much how you're planning to use your class - it's hard to offer alternative design advice on how to achieve better type safety.

EDIT: You should look at the type converter option that Marc and others recommend. This seems like the way to go.

EDIT: One possible idea that occurs to me, is to make the Parse() method actually be a delegate: Func<string,T> - that you assign during construction. This would make it possible for you to:

1. Avoid the inefficient and awkward if/else logic.
2. Improve the future use of your class to other value types (structs, BigDecimal, etc)

Here's a code example of what I mean:

class MyClass<T>
{
    private readonly Func<string,T> ParseEntry;

    public MyClass( Func<string,T> parser )    
    {
        ParseEntry = parser;
    }
}

public static class AvailableParsers
{
    public static Func<string,int> ParseInt = s => int.Parse( s );
    public static Func<string,float> ParseFloat = s => float.Parse(s);
}

You can read about the available constraints here. The only constraints available are:

• struct (optional)
• new() (optional)
• interface constraint (optional, multiple allows)
• base class constraint (optional, only one allowed)
• naked constraints ( such as where T : TResult )

Answer 2

Stupid maybe, but - if you are talking about a limited set of types, why don't you just overload the method? Like the *Writer.Write() methods, that have overloads for every "base" type?

In short: Why generic, if you do different things based on the type anyway (that somehow defeats the purpose of doing the same thing for whatever type is passed in)?

---

Edit: Thinking about the usage I think you might actually want to use Convert.ChangeType.

Something like this:

class MyClass<T> where T: IConvertible
{
    private static T ParseEntry(string entry)
    {
        return (T)Convert.ChangeType(entry, typeof(T));
    }
}

Answer 3

Like Mr. Bushkin said, you can't do that. So you're other option would be to simply make several overloads of the method for each primitive type.

Also, imagine that you didn't have to deal with primitive types, but you really wanted to handle all structs - it still wouldn't be possible, since the struct is not guaranteed to implement an (heretofore imaginary) interface called IParsable to be cast into T.

Answer 4

I guess I don't see the value here... why not use the Convert class?

Answer 5

private static T ParseEntry(string entry)
{
    TypeConverter conv = TypeDescriptor.GetConverter(typeof(T));
    return (T) conv.ConvertFromString(entry);
}

which has the advantage of working with any type with a type-converter (or you can add your own at runtime). It does have boxing, but really, it isn't so bad. If that is your biggest problem, then you're going about this the wrong way.