Czy operator == nie może być stosowany do typów ogólnych w C #?

Zgodnie z dokumentacją ==operatora w MSDN ,

W przypadku predefiniowanych typów wartości operator równości (==) zwraca wartość true, jeśli wartości jego argumentów są równe, w przeciwnym razie false. W przypadku typów odwołań innych niż łańcuch == zwraca wartość true, jeśli dwa operandy odnoszą się do tego samego obiektu. Dla typu ciągu == porównuje wartości ciągów. Zdefiniowane przez użytkownika typy wartości mogą przeciążać operatora == (patrz operator). Podobnie mogą być typy referencyjne zdefiniowane przez użytkownika, chociaż domyślnie == zachowuje się tak, jak opisano powyżej, zarówno dla typów predefiniowanych, jak i zdefiniowanych przez użytkownika.

Dlaczego więc ten fragment kodu się nie kompiluje?

bool Compare<T>(T x, T y) { return x == y; }

Pojawia się błąd Operator „==” nie może być stosowany do operandów typu „T” i „T” . Zastanawiam się, dlaczego, skoro o ile rozumiem, ==operator jest predefiniowany dla wszystkich typów?

Edycja: Dzięki wszystkim. Z początku nie zauważyłem, że stwierdzenie dotyczy tylko typów referencji. Pomyślałem też, że porównanie bit po bicie jest dla wszystkich typów wartości, co wiem teraz jest nie poprawny.

Ale w przypadku, gdy korzystam z typu odniesienia, czy ==operator użyłby wstępnie zdefiniowanego porównania odniesienia, czy użyłby przeciążonej wersji operatora, jeśli typ byłby zdefiniowany?

Edycja 2: Dzięki próbom i błędom dowiedzieliśmy się, że ==operator użyje predefiniowanego porównania referencyjnego, gdy użyje nieograniczonego typu ogólnego. Właściwie kompilator użyje najlepszej metody, jaką może znaleźć dla argumentu typu ograniczonego, ale nie będzie dalej szukał. Na przykład poniższy kod zawsze będzie drukowany true, nawet gdy Test.test<B>(new B(), new B())zostanie wywołany:

class A { public static bool operator==(A x, A y) { return true; } }
class B : A { public static bool operator==(B x, B y) { return false; } }
class Test { void test<T>(T a, T b) where T : A { Console.WriteLine(a == b); } }

„... domyślnie == zachowuje się tak, jak opisano powyżej, zarówno dla predefiniowanych, jak i zdefiniowanych przez użytkownika typów referencji.”

Typ T niekoniecznie jest typem referencyjnym, więc kompilator nie może przyjąć tego założenia.

Jednak to się skompiluje, ponieważ jest bardziej jednoznaczne:

    bool Compare<T>(T x, T y) where T : class
    {
        return x == y;
    }

Postępuj zgodnie z dodatkowym pytaniem: „Ale w przypadku, gdy używam typu odniesienia, operator == użyłby wstępnie zdefiniowanego porównania odniesienia, czy użyłby przeciążonej wersji operatora, jeśli typ zdefiniowałby?”

Myślałem, że == w Generics użyłby przeciążonej wersji, ale poniższy test pokazuje inaczej. Ciekawe ... Chciałbym wiedzieć, dlaczego! Jeśli ktoś wie, udostępnij.

namespace TestProject
{
 class Program
 {
    static void Main(string[] args)
    {
        Test a = new Test();
        Test b = new Test();

        Console.WriteLine("Inline:");
        bool x = a == b;
        Console.WriteLine("Generic:");
        Compare<Test>(a, b);

    }


    static bool Compare<T>(T x, T y) where T : class
    {
        return x == y;
    }
 }

 class Test
 {
    public static bool operator ==(Test a, Test b)
    {
        Console.WriteLine("Overloaded == called");
        return a.Equals(b);
    }

    public static bool operator !=(Test a, Test b)
    {
        Console.WriteLine("Overloaded != called");
        return a.Equals(b);
    }
  }
}

Wynik

Inline: Przeciążony == wywołany

Rodzajowy:

Naciśnij dowolny klawisz, aby kontynuować . . .

Kontynuacja 2

Chcę podkreślić, że zmieniając moją metodę porównywania na

    static bool Compare<T>(T x, T y) where T : Test
    {
        return x == y;
    }

powoduje wywołanie przeciążonego operatora ==. Wydaje mi się, że bez podania typu (jako miejsca ) kompilator nie może wywnioskować, że powinien użyć przeciążonego operatora ... choć sądzę, że będzie miał wystarczającą ilość informacji, aby podjąć decyzję nawet bez podania typu.

Jak powiedzieli inni, będzie działać tylko wtedy, gdy T jest ograniczony do typu odniesienia. Bez żadnych ograniczeń można porównać z wartością null, ale tylko z wartością null - i to porównanie zawsze będzie fałszywe dla typów wartości, które nie mają wartości zerowych.

Zamiast wywoływać Equals, lepiej użyć IComparer<T> - a jeśli nie masz więcej informacji, EqualityComparer<T>.Defaultto dobry wybór:

public bool Compare<T>(T x, T y)
{
    return EqualityComparer<T>.Default.Equals(x, y);
}

Oprócz czegokolwiek innego, pozwala to uniknąć boksu / castingu.

Ogólnie rzecz biorąc, EqualityComparer<T>.Default.Equalspowinien wykonywać pracę ze wszystkim, co implementujeIEquatable<T> lub ma sensowną Equalsimplementację.

Jeśli jednak ==i Equalsz jakiegoś powodu są wdrażane inaczej, moja praca nad operatorami rodzajowymi powinna być użyteczna; wspiera operatora wersje (między innymi):

• Równa (wartość T1, wartość T2)
• NotEqual (wartość T1, wartość T2)
• GreaterThan (wartość T1, wartość T2)
• LessThan (wartość T1, wartość T2)
• GreaterThanOrEqual (wartość T1, wartość T2)
• LessThanOrEqual (wartość T1, wartość T2)

Tak wiele odpowiedzi, a żadna z nich nie wyjaśnia DLACZEGO? (o co wyraźnie poprosił Giovanni) ...

Generyczne .NET nie działają jak szablony C ++. W szablonach C ++ rozwiązywanie przeciążenia występuje po poznaniu rzeczywistych parametrów szablonu.

W generycznych .NET (w tym C #) rozwiązywanie przeciążeń występuje bez znajomości rzeczywistych parametrów ogólnych. Jedyne informacje, których kompilator może użyć do wybrania funkcji do wywołania, pochodzą z ograniczeń typu w parametrach ogólnych.

Kompilacja nie może wiedzieć, że T nie może być strukturą (typ wartości). Więc musisz powiedzieć, że może to być tylko typ referencyjny, myślę:

bool Compare<T>(T x, T y) where T : class { return x == y; }

Jest tak, ponieważ jeśli T może być typem wartości, mogą istnieć przypadki, w których x == ybyłby źle sformułowany - w przypadkach, gdy typ nie ma zdefiniowanego operatora ==. To samo stanie się z tym, co jest bardziej oczywiste:

void CallFoo<T>(T x) { x.foo(); }

To też się nie udaje, ponieważ można przekazać typ T, który nie miałby funkcji foo. C # zmusza cię do upewnienia się, że wszystkie możliwe typy zawsze mają funkcję foo. Robi to klauzula where.

Wygląda na to, że bez ograniczenia klasy:

bool Compare<T> (T x, T y) where T: class
{
    return x == y;
}

Należy zdawać sobie sprawę, że będąc classograniczonym Equalsw== operatora dziedziczy Object.Equals, podczas gdy struktura zastępujeValueType.Equals .

Uwaga:

bool Compare<T> (T x, T y) where T: struct
{
    return x == y;
}

podaje również ten sam błąd kompilatora.

Jak dotąd nie rozumiem, dlaczego kompilator odrzuca porównanie operatora równości typu wartości. Wiem jednak na pewno, że to działa:

bool Compare<T> (T x, T y)
{
    return x.Equals(y);
}

W moim przypadku chciałem przetestować jednostkę operatora równości. Potrzebowałem wywołać kod w ramach operatorów równości bez jawnego ustawiania typu ogólnego. Porady dla EqualityComparernie były przydatne jako metoda EqualityComparernazywana Equals, ale nie były operatorem równości.

Oto jak mam to pracować z typami rodzajowymi, budując LINQ. Wywołuje odpowiedni kod ==i !=operatory:

/// <summary>
/// Gets the result of "a == b"
/// </summary>
public bool GetEqualityOperatorResult<T>(T a, T b)
{
    // declare the parameters
    var paramA = Expression.Parameter(typeof(T), nameof(a));
    var paramB = Expression.Parameter(typeof(T), nameof(b));
    // get equality expression for the parameters
    var body = Expression.Equal(paramA, paramB);
    // compile it
    var invokeEqualityOperator = Expression.Lambda<Func<T, T, bool>>(body, paramA, paramB).Compile();
    // call it
    return invokeEqualityOperator(a, b);
}

/// <summary>
/// Gets the result of "a =! b"
/// </summary>
public bool GetInequalityOperatorResult<T>(T a, T b)
{
    // declare the parameters
    var paramA = Expression.Parameter(typeof(T), nameof(a));
    var paramB = Expression.Parameter(typeof(T), nameof(b));
    // get equality expression for the parameters
    var body = Expression.NotEqual(paramA, paramB);
    // compile it
    var invokeInequalityOperator = Expression.Lambda<Func<T, T, bool>>(body, paramA, paramB).Compile();
    // call it
    return invokeInequalityOperator(a, b);
}

Jest to wpis MSDN Connect dla tego tutaj

Odpowiedź Alexa Turnera zaczyna się od:

Niestety takie zachowanie jest zgodne z projektem i nie ma łatwego rozwiązania umożliwiającego użycie == z parametrami typu, które mogą zawierać typy wartości.

Jeśli chcesz się upewnić, że operatorzy niestandardowego typu są nazywani, możesz to zrobić przez odbicie. Wystarczy pobrać typ za pomocą parametru ogólnego i pobrać MethodInfo dla żądanego operatora (np. Op_Equality, op_Inequality, op_LessThan ...).

var methodInfo = typeof (T).GetMethod("op_Equality", 
                             BindingFlags.Static | BindingFlags.Public);    

Następnie uruchom operator za pomocą metody Invoke MethodInfo i przekaż obiekty jako parametry.

var result = (bool) methodInfo.Invoke(null, new object[] { object1, object2});

Spowoduje to wywołanie przeciążonego operatora, a nie tego określonego przez ograniczenia nałożone na parametr ogólny. Może to nie być praktyczne, ale może się przydać do testowania jednostkowego operatorów przy użyciu ogólnej klasy bazowej, która zawiera kilka testów.

Napisałem następującą funkcję, patrząc na najnowszy msdn. Może łatwo porównywać dwa obiekty xi y:

static bool IsLessThan(T x, T y) 
{
    return ((IComparable)(x)).CompareTo(y) <= 0;
}

bool Compare(T x, T y) where T : class { return x == y; }

Powyższe zadziała, ponieważ == jest załatwiane w przypadku typów referencyjnych zdefiniowanych przez użytkownika.
W przypadku typów wartości == można zastąpić. W takim przypadku należy również zdefiniować „! =”.

Myślę, że może to być przyczyną, nie pozwala na ogólne porównanie przy użyciu „==”.

.Equals()Pracuje dla mnie natomiast TKeyto typ rodzajowy.

public virtual TOutputDto GetOne(TKey id)
{
    var entity =
        _unitOfWork.BaseRepository
            .FindByCondition(x => 
                !x.IsDelete && 
                x.Id.Equals(id))
            .SingleOrDefault();


    // ...
}