IComparable with Enums sent as generic type parameters (C#)

Question

Possible Duplicate:
When are two enums equal in C#?

I have the following classes as part of a simple state machine.

Please note that all generic type parameters HAVE to be an enumeration. That has been enforced in the constructors (not shown here).

// Both [TState] and [TCommand] will ALWAYS be enumerations.
public class Transitions<TState, TCommand>: List<Transition<TState, TCommand>>
{
    public new void Add (Transition<TState, TCommand> item)
    {
        if (this.Contains(item))
            throw (new InvalidOperationException("This transition already exists."));
        else
            this.Add(item);
    }
}

// Both [TState] and [TCommand] will ALWAYS be enumerations.
public class Transition<TState, TCommand>
{
    TState From = default(TState);
    TState To  = default(TState);
    TCommand Command = default(TCommand);
}

public sealed class TransitionComparer<TState>:
    IComparer<TState>
{
    public int Compare (TState x, TState y)
    {
        int result = 0;

        // How to compare here since TState is not strongly typed and is an enum?
        //    Using ToString seems silly here.

        result |= x.From.ToString().CompareTo(y.From.ToString());
        result |= x.To.ToString().CompareTo(y.To.ToString());
        result |= x.Command.ToString().CompareTo(y.Command.ToString());

        return (result);
    }
}

The above does compile but I'm not sure if this is the right way to handle enums that have been passed in as generic type parameters.

Note: The compare function does not need to keep ordering in mind. Rather it needs to check for exact duplicates.

Jon Skeet · Accepted Answer · 2012-09-24T06:06:43.823

3

Note: The compare function does not need to keep ordering in mind. Rather it needs to check for exact duplicates.

In that case, you shouldn't be implementing IComparer<T>. You should be implementing IEqualityComparer<T> - or, more simply, make Transition implement IEquatable<Transition>.

Note that you're currently not using the TransitionComparer in the rest of the code, as far as we can see. It sounds like you shouldn't really need to write your own comparison code for each enum value - you're just trying to combine them. Unfortunately enums don't implement IEquatable<T>, which makes is a bit harder to do this without boxing - how performance critical is this?

Here's a sample equality implementation for Transition:

public class Transition<TState, TCommand>
    : IEquatable<Transition<TState, TCommand>>
{
    // I assume in reality these are properties?
    TState From = default(TState);
    TState To  = default(TState);
    TCommand Command = default(TCommand);

    public override bool Equals(object other)
    {
        return Equals(other as Transition<TState, TCommand>);
    }

    public bool Equals(Transition<TState, TCommand> other)
    {
        if (other == null)
        {
            return false;
        }
        return From.Equals(other.From) &&
               To.Equals(other.To) &&
               Command.Equals(other.Command);
    }

    public int GetHashCode()
    {
        int hash = 17;
        hash = hash * 31 + From.GetHashCode();
        hash = hash * 31 + To.GetHashCode();
        hash = hash * 31 + Command.GetHashCode();
        return hash;
    }
}

EDIT: To avoid boxing for equality, I suspect you would either need some kind of delegate to get at the underlying value (and if you need to support values with different underlying types, that's pretty painful) or potentially use something like Unconstrained Melody which uses IL rewriting to enforce the constraint at compile time, and allows you to check for equality based on underlying value more efficiently.

edited Sep 24 '12 at 06:06

answered Sep 24 '12 at 05:59

Jon Skeet

1,421,763
867
9,128
9,194

Thanks. I am writing this as a library for future projects, some of which may be performance critical. Would you approach it any different in that case? And yes, you are right, The comparer itself is not being used anywhere. – Raheel Khan Sep 24 '12 at 06:06
@RaheelKhan: I'll add an edit. – Jon Skeet Sep 24 '12 at 06:07
Thanks Jon, for correcting my mistake, the implementation and link to UM! I'll prototype with boxing and look at UM in the meanwhile. – Raheel Khan Sep 24 '12 at 06:19
I tried accessing Unconstrained Melody from a number of machines in vain and was wondering if it is down for others. – Raheel Khan Sep 24 '12 at 06:31
@RaheelKhan: It's working for me. Is Google Code in general out for you? – Jon Skeet Sep 24 '12 at 06:37
It seems Google Code is not accessible for me only over HTTP. I should be able to find the SVN and connect though. – Raheel Khan Sep 24 '12 at 07:24
@RaheelKhan: Okay - it's `svn checkout http://unconstrained-melody.googlecode.com/svn/trunk/ unconstrained-melody-read-only` – Jon Skeet Sep 24 '12 at 07:25
Just revisiting old questions. Is there a specific reason you have used those particular numbers in GetHashCode? I am not very clear on how it is supposed to be implemented. – Raheel Khan Jun 21 '13 at 05:43
@RaheelKhan: Those numbers are just ones which I believe work well. The maths behind it is tricky, IIRC. The fact that both numbers are prime may well be useful, and multiplying by 31 can be optimized into shift then subtract. Basically I take this approach from Josh Bloch :) – Jon Skeet Jun 21 '13 at 05:50

score -1 · Answer 2 · answered Sep 24 '12 at 06:02

-1

I can't see anything than

(int)(object)x.From.CompareTo((int)(object)y.From);

The enums are boxed. I don't know how this could be avoided.

answered Sep 24 '12 at 06:02

Stefan Steinegger

63,782
15
129
193

That's assuming we know the underlying type is `int`, of course. – Jon Skeet Sep 24 '12 at 06:08
True. But still might work in a specific project. It won't be framework code. – Stefan Steinegger Sep 24 '12 at 06:09
It may indeed work - I just think it would be worth noting as a restriction. – Jon Skeet Sep 24 '12 at 06:11

IComparable with Enums sent as generic type parameters (C#)

2 Answers2