Чи не можна застосувати оператор == до загальних типів у C #?

Відповідно до документації ==оператора в MSDN ,

Для заданих типів значень оператор рівності (==) повертає істину, якщо значення його операндів рівні, інакше помилкові. Для типів посилань, крім рядка, == повертає значення true, якщо два його операнди посилаються на один і той же об'єкт. Для типу рядка == порівнює значення рядків. Визначені користувачем типи значень можуть перевантажувати оператор == (див. Оператор). Так можна визначати користувальницькі типи посилань, хоча за замовчуванням == поводиться так, як описано вище для попередньо визначених та визначених користувачем посилальних типів.

То чому цей фрагмент коду не може скластися?

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

Я отримую помилку Оператор '==' не може бути застосований до операндів типу 'T' і 'T' . Цікаво, чому, оскільки наскільки я розумію, ==оператор заздалегідь визначений для всіх типів?

Редагувати: Спасибі всім Я спочатку не помітив, що твердження стосується лише типів посилань. Я також думав , що порівняння біт за бітом надається для всіх типів значень, які я тепер знаю , це НЕ правильно.

Але, у випадку, коли я використовую тип посилання, чи ==використовував би оператор попередньо визначене порівняння посилань, чи використовував би перевантажений варіант оператора, якщо тип визначений?

Редагування 2: Через пробу та помилку ми дізналися, що ==оператор буде використовувати заздалегідь задане порівняння при використанні необмеженого загального типу. Насправді компілятор використовуватиме найкращий метод, який він може знайти для аргументу обмеженого типу, але далі не шукатиме. Наприклад, код нижче завжди буде надруковано true, навіть коли Test.test<B>(new B(), new B())він викликається:

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); } }

"... за замовчуванням == поводиться так, як описано вище для попередньо визначених та визначених користувачем типів посилань."

Тип T не обов'язково є референтним типом, тому компілятор не може зробити таке припущення.

Однак це буде компілюватися, оскільки воно є більш явним:

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

Додаткове запитання: "Але, якщо я використовую тип посилання, чи використовував би оператор == попередньо задане порівняння порівняння, чи використовував би перевантажену версію оператора, якщо тип визначений?"

Я б подумав, що == на Generics використовує перевантажену версію, але наступний тест демонструє інше. Цікаво ... Я хотів би знати чому! Якщо хтось знає, будь ласка, поділіться.

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);
    }
  }
}

Вихідні дані

Вбудований: Перевантажений == викликається

Загальне:

Натисніть будь-яку кнопку, щоб продовжити . . .

Продовження 2

Я хочу зазначити, що я міняю метод порівняння на

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

викликає виклик оператора перевантаженого ==. Думаю, не вказуючи тип (як де ), компілятор не може зробити висновок, що він повинен використовувати перевантажений оператор ... хоча я думаю, що у нього буде достатньо інформації для прийняття цього рішення навіть без зазначення типу.

Як вже говорили інші, вона працюватиме лише тоді, коли T обмежується бути еталонним типом. Без будь-яких обмежень, ви можете порівнювати з null, але лише з null - і це порівняння завжди буде помилковим для ненульових типів значень.

Замість того, щоб називати рівними, краще скористатись IComparer<T>- і якщо у вас немає більше інформації, EqualityComparer<T>.Default- хороший вибір:

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

Крім усього іншого, це дозволяє уникнути боксу / кастингу.

Взагалі, EqualityComparer<T>.Default.Equalsслід виконувати роботу з будь-чим, що реалізує IEquatable<T>, або що має розумну Equalsреалізацію.

Якщо ж ==і Equalsчомусь реалізуються по-різному, то моя робота над загальними операторами повинна бути корисною; він підтримує операторські версії (серед інших):

• Дорівнює (значення T1, значення T2)
• NotEqual (значення T1, значення T2)
• Більше ніж (значення T1, значення T2)
• Менше ніж (значення T1, значення T2)
• GreaterThanOrEqual (значення T1, значення T2)
• LessThanOrEqual (значення T1, значення T2)

Чому багато відповідей, а жодна не пояснює ЧОМУ? (про що відверто запитав Джованні) ...

.NET generics не діють як шаблони C ++. У шаблонах C ++ роздільна здатність перевантаження виникає після того, як будуть відомі фактичні параметри шаблону.

У .NET generics (включаючи C #) роздільна здатність перевантаження відбувається без знання фактичних загальних параметрів. Єдина інформація, яку компілятор може використовувати для вибору функції для виклику, походить від обмежень типу на загальні параметри.

Компіляція не може знати, що T не може бути структурою (тип значення). Тож ви мусите сказати це, я можу бути лише еталонного типу, я думаю:

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

Це тому, що якщо T може бути типом значення, то можуть виникнути випадки, коли x == yбуде неправильно формуватися - у випадках, коли для типу не визначено оператора ==. Те саме відбудеться і для цього, що більш очевидно:

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

Це також не вдається, тому що ви можете передати тип T, який би не мав функції foo. C # змушує вас переконатися, що всі можливі типи завжди мають функцію foo. Це робиться за допомогою пункту де.

Виявляється, що без обмеження класу:

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

Слід розуміти , що в той час classобмежені Equalsв ==оператор успадковує від Object.Equals, в той час як на структуру перевизначення ValueType.Equals.

Зауважте, що:

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

також видає ту саму помилку компілятора.

Поки я не розумію, чому порівняння оператора рівності типу значення відхиляється компілятором. Я фактично знаю, що це працює:

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

Ну а в моєму випадку я хотів перевірити одиницю рівності. Мені потрібно було викликати код під операторами рівності, не чітко встановлюючи загальний тип. Поради EqualityComparerне були корисними як EqualityComparerназиваний Equalsметод, але не оператор рівності.

Ось як я працював із загальними типами, будуючи LINQ. Він називає правильний код ==і !=операторів:

/// <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);
}

Існує запис MSDN Connect для цього тут

Відповідь Алекса Тернера починається з:

На жаль, така поведінка є конструктивною, і не існує простого рішення, щоб дозволити використання == з параметрами типу, які можуть містити типи значень.

Якщо ви хочете переконатися, що оператори вашого користувальницького типу викликаються, ви можете зробити це за допомогою рефлексії. Просто отримайте тип за допомогою свого загального параметра та отримайте MethodInfo для потрібного оператора (наприклад, op_Equality, op_Inequality, op_LessThan ...).

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

Потім виконайте оператор, використовуючи метод Invoke MethodInfo і передайте об'єкти як параметри.

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

Це викликає ваш перевантажений оператор, а не той, який визначений обмеженнями, застосованими до загального параметра. Це може бути не практично, але може стати в нагоді для тестування підрозділів операторів при використанні загального базового класу, який містить пару тестів.

Я написав таку функцію, дивлячись на останній msdn. Тут можна легко порівняти два об'єкти xта 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; }

Вищезазначене буде працювати, оскільки == доглядають у випадку визначених користувачем посилальних типів.
У випадку типів значень == може бути замінено У цьому випадку також слід визначити "! =".

Я думаю, що це може бути причиною, це відключає загальне порівняння, використовуючи "==".

.Equals()Працює для мене в той час як TKeyце загальний тип.

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


    // ...
}