цепочка bools в C #

Question

цепочка bools в C #

2

int a, b, c, d, e;
a = b = c = d = e = 1;

if ((a==b) && (b==c) && (c==d) && (d==e))
{
    Console.WriteLine("that syntax is horrible");
}

есть ли более элегантный способ проверить множественное равенство, как указано выше?

может быть AreEqual(params obj[]) или что-то еще? У меня был Google, но ничего не нашел.

fearofawhackplanet 07 янв. 2010, в 12:27

Источник

0

Элегантный: (a & b & c & d & e) == (a | b | c | d | e), но не так легко понять.
Skizz 07 янв. 2010, в 13:42

Теги:

c#

.net

5 ответов

4

Вот общая версия, которая позволит избежать бокса (и быть более безопасным во время компиляции):

public static bool AllEqual<T>(T firstItem, params T[] items)
{
    // Omitted error checking
    EqualityComparer<T> comparer = EqualityComparer<T>.Default;
    foreach (T item in items)
    {
        if (!comparer.Equals(firstItem, item))
        {
            return false;
        }
    }
    return true;
}

Обратите внимание, что это будет не так удобно, если вы действительно хотите передать кучу значений, которые вы уже получили в массиве, но избегаете проблем с пустыми массивами - и означает, что у вас нет избыточных сравнений.

Jon Skeet 07 янв. 2010, в 09:12

0

Это не то же самое, что оригинал; (если вы переопределите 'Equals', это будет использовать эту реализацию).
Noon Silk 07 янв. 2010, в 11:40
1

@silky: Какую версию вы предлагаете не использовать переопределенные Equals? Единственная разница будет в том, если кто-то реализует Equals (объект) иначе, чем его реализация IEqualityComparer - в этом случае у него возникают большие проблемы с IMO.
Jon Skeet 07 янв. 2010, в 12:21
0

Джон: Оригинал (то есть код ОП). И нет, это имело бы значение, если бы он действительно хотел сделать сравнительное сравнение. Конечно, это маловероятно, но показывает вредность наивного преобразования в какую-то сложную схему, которая, в конечном счете, ИМХО, менее читабельна и даже не требуется.
Noon Silk 07 янв. 2010, в 12:36
2

@silky: вы не можете реализовать универсальный метод, который использует == для сравнения в .NET. Equals - это единственный способ, который гарантируется руководящими принципами реализации в соответствии с реализацией == . Если равенство ссылок является обязательной операцией, просто создайте дополнительную перегрузку. Но ваше предположение, что OP, вероятно, означало равенство ссылок (несмотря на то, что его пример был с int s), совершенно странно.
Konrad Rudolph 07 янв. 2010, в 13:30
0

Конрад: Re ваш первый пункт: это именно то, что я говорю. Я сижу здесь довольно ошеломленно, что у меня даже есть разговор о чем-то настолько нелепом, как общий метод сравнения точного равенства списка объектов. Просто очень странно, когда есть так много лучших способов сделать это. Я не буду больше тратить время здесь.
Noon Silk 07 янв. 2010, в 13:34
0

@silky: нет, пожалуйста, побалуй меня. Так что, может быть, это плохо для обсуждения, но речь идет о решениях, и я не понимаю, как Джон не является хорошим решением. Что такого «совершенно смешного» и «странного» в этом методе? - Всегда при условии, что пользователи знают, что они делают, и что они следуют рекомендациям по внедрению Equals - но это всегда требуется при работе с библиотеками .NET, поэтому само собой разумеется.
Konrad Rudolph 07 янв. 2010, в 14:05
0

Конрад: Вы показываете мне пример того, когда вы когда-либо будете использовать это. Настоящий пример. Я говорю вам, вы не придумаете тот, который не был бы лучше сделать с помощью редизайна set / pattern / switch / general. Джон предоставил «решение» проблемы, которая не должна быть решена. ОП явно новичок, и этот подход (и принятый), IMHO, плохая практика. Но, к сожалению, я заметил это ранее с Джоном (и другими), и это не имеет значения для них, что я нахожу действительно запутанным. Конечно, дело не в том, чтобы быть «крутым» с LINQ и т. Д., А в том, что лучше.
Noon Silk 07 янв. 2010, в 14:22
0

@silky: Разве это не совсем другое обсуждение? Что бы это ни стоило, я не знаю ни одного варианта использования на макушке. С другой стороны, многим кажется, что это достаточно полезно, так как Python ввел для него специальный синтаксис ( a == b == c == d ). Это априори плохой дизайн? Это звучит немного чрезмерно обобщенно.
Konrad Rudolph 07 янв. 2010, в 14:43
0

@silky: оригинал, код OP, использует только целые числа. Как бы вы переопределили реализацию Equals int? Что касается того , что это когда - нибудь полезным - я могу себе представить , есть случаи , когда вы хотите , чтобы равенство для всей последовательности, но вы предположили , что это плохой дизайн.
Jon Skeet 07 янв. 2010, в 15:11
0

@silky: Что касается вашего комментария о предоставлении ответов на вещи, которые не должны быть сделаны - см. stackoverflow.com/questions/2020373 для контрпример. Тебе приходило в голову, что, может быть, мы просто не согласны с тем, какие вещи определенно не следует делать, а какие на самом деле могут иметь веские причины?
Jon Skeet 07 янв. 2010, в 15:15
0

Джон: Я не говорю, что вы делаете это все время, и я не говорю, что это ограничено вами, но это происходит чаще, чем следовало бы (с большим количеством плакатов). Конрад: Нет, это не совсем другой вопрос; в этом- то и дело: у автора плаката есть проблема, которую он пытается решить «лучшим» способом, но основной подход неверен. Поэтому уместно прояснить это (по крайней мере, это то, что я предпочитаю делать). Я просто не согласен с подходом Джона и подчеркиваю ошибку. Джон: Как Konrad, не стесняйтесь , чтобы объяснить , как именно это могло бы быть хорошо.
Noon Silk 07 янв. 2010, в 21:31

Показать ещё 9 комментариев

3

Нет, это самый разумный способ (я имею в виду наиболее читаемый, что является самым важным).

Реальный вопрос: зачем вам это нужно? Похоже, что плохой дизайн в первую очередь...

Noon Silk 07 янв. 2010, в 09:37

0

с какой стати может быть плохим дизайном необходимость проверять, равняется ли куча вещей? Вы честно говорите, что нет никаких причин, чтобы когда-либо это делать? это именно тот комментарий «общего мнения», который я нахожу таким разочаровывающим с этим сайтом. Хотите, чтобы я опубликовал все 50К строк кода, чтобы вы могли понять, почему я хочу это сделать?
fearofawhackplanet 07 янв. 2010, в 11:26
0

В значительной степени я говорю, что да; нет особой причины расстраиваться из-за моего ответа. Я оставлю тебя к этому.
Noon Silk 07 янв. 2010, в 11:35
2

Я не думаю, что он имел в виду, что вам никогда не понадобится проверять, совпадает ли куча вещей, просто существует более краткий способ выполнения действий (в зависимости от остальной части вашего кода).
Justin Rusbatch 07 янв. 2010, в 12:19

Показать ещё 1 комментарий

0

Если вы сравниваете простые типы, и у вас есть только несколько вариантов использования, вы можете создать несколько полезных методов, таких как:

    bool AllEqual(int first, params int[] numbers)
    {
        return numbers.All(x => x == first);
    }

Jamie Ide 07 янв. 2010, в 10:39

0

~~Это весело~~

int a, b, c, d, e;
a = b = c = d = e = 1;

if ((a & b & c & d) == e)
{
    Console.WriteLine("that syntax is horrible");
}

Забастовкa >

и, возможно, лучше

int a, b, c, d, e;
a = b = c = d = e = 1;
if (new[] {a, b, c, d, e}.All(i => i == a))
{
    Console.WriteLine("Funky chicken");
}

mcintyre321 07 янв. 2010, в 10:37

0

Этот код даст неправильные результаты. Обратите внимание, что & делает побитово и. Результат оказывается правильным, если все значения равны, но он может быть неправильным для разных значений (т. Е. Результат все равно будет true хотя значения не все равны).
Konrad Rudolph 07 янв. 2010, в 13:33
0

хех так оно и есть :)
mcintyre321 07 янв. 2010, в 13:37

Ещё вопросы

Элегантный: (a & b & c & d & e) == (a | b | c | d | e), но не так легко понять.
Это не то же самое, что оригинал; (если вы переопределите 'Equals', это будет использовать эту реализацию).
@silky: Какую версию вы предлагаете не использовать переопределенные Equals? Единственная разница будет в том, если кто-то реализует Equals (объект) иначе, чем его реализация IEqualityComparer - в этом случае у него возникают большие проблемы с IMO.
Джон: Оригинал (то есть код ОП). И нет, это имело бы значение, если бы он действительно хотел сделать сравнительное сравнение. Конечно, это маловероятно, но показывает вредность наивного преобразования в какую-то сложную схему, которая, в конечном счете, ИМХО, менее читабельна и даже не требуется.
@silky: вы не можете реализовать универсальный метод, который использует == для сравнения в .NET. Equals - это единственный способ, который гарантируется руководящими принципами реализации в соответствии с реализацией == . Если равенство ссылок является обязательной операцией, просто создайте дополнительную перегрузку. Но ваше предположение, что OP, вероятно, означало равенство ссылок (несмотря на то, что его пример был с int s), совершенно странно.
Конрад: Re ваш первый пункт: это именно то, что я говорю. Я сижу здесь довольно ошеломленно, что у меня даже есть разговор о чем-то настолько нелепом, как общий метод сравнения точного равенства списка объектов. Просто очень странно, когда есть так много лучших способов сделать это. Я не буду больше тратить время здесь.
@silky: нет, пожалуйста, побалуй меня. Так что, может быть, это плохо для обсуждения, но речь идет о решениях, и я не понимаю, как Джон не является хорошим решением. Что такого «совершенно смешного» и «странного» в этом методе? - Всегда при условии, что пользователи знают, что они делают, и что они следуют рекомендациям по внедрению Equals - но это всегда требуется при работе с библиотеками .NET, поэтому само собой разумеется.
Конрад: Вы показываете мне пример того, когда вы когда-либо будете использовать это. Настоящий пример. Я говорю вам, вы не придумаете тот, который не был бы лучше сделать с помощью редизайна set / pattern / switch / general. Джон предоставил «решение» проблемы, которая не должна быть решена. ОП явно новичок, и этот подход (и принятый), IMHO, плохая практика. Но, к сожалению, я заметил это ранее с Джоном (и другими), и это не имеет значения для них, что я нахожу действительно запутанным. Конечно, дело не в том, чтобы быть «крутым» с LINQ и т. Д., А в том, что лучше.
@silky: Разве это не совсем другое обсуждение? Что бы это ни стоило, я не знаю ни одного варианта использования на макушке. С другой стороны, многим кажется, что это достаточно полезно, так как Python ввел для него специальный синтаксис ( a == b == c == d ). Это априори плохой дизайн? Это звучит немного чрезмерно обобщенно.
@silky: оригинал, код OP, использует только целые числа. Как бы вы переопределили реализацию Equals int? Что касается того , что это когда - нибудь полезным - я могу себе представить , есть случаи , когда вы хотите , чтобы равенство для всей последовательности, но вы предположили , что это плохой дизайн.
@silky: Что касается вашего комментария о предоставлении ответов на вещи, которые не должны быть сделаны - см. stackoverflow.com/questions/2020373 для контрпример. Тебе приходило в голову, что, может быть, мы просто не согласны с тем, какие вещи определенно не следует делать, а какие на самом деле могут иметь веские причины?
Джон: Я не говорю, что вы делаете это все время, и я не говорю, что это ограничено вами, но это происходит чаще, чем следовало бы (с большим количеством плакатов). Конрад: Нет, это не совсем другой вопрос; в этом- то и дело: у автора плаката есть проблема, которую он пытается решить «лучшим» способом, но основной подход неверен. Поэтому уместно прояснить это (по крайней мере, это то, что я предпочитаю делать). Я просто не согласен с подходом Джона и подчеркиваю ошибку. Джон: Как Konrad, не стесняйтесь , чтобы объяснить , как именно это могло бы быть хорошо.
с какой стати может быть плохим дизайном необходимость проверять, равняется ли куча вещей? Вы честно говорите, что нет никаких причин, чтобы когда-либо это делать? это именно тот комментарий «общего мнения», который я нахожу таким разочаровывающим с этим сайтом. Хотите, чтобы я опубликовал все 50К строк кода, чтобы вы могли понять, почему я хочу это сделать?
В значительной степени я говорю, что да; нет особой причины расстраиваться из-за моего ответа. Я оставлю тебя к этому.
Я не думаю, что он имел в виду, что вам никогда не понадобится проверять, совпадает ли куча вещей, просто существует более краткий способ выполнения действий (в зависимости от остальной части вашего кода).
Этот код даст неправильные результаты. Обратите внимание, что & делает побитово и. Результат оказывается правильным, если все значения равны, но он может быть неправильным для разных значений (т. Е. Результат все равно будет true хотя значения не все равны).

Aviad P. · Accepted Answer · 2010-01-07T09-18-00.000Z

Возможная реализация AreEqual(params object[] objects):

(Следуя совету Джона Скита, здесь общая версия)

bool AreEqual<T>(params T[] objects)
{
    if (objects.Length <= 1) return true;
    return objects.Skip(1).All(x => x.Equals(objects[0]));
}

Skip(1) также не является строго необходимым.

спасибо Aviad, я знаю, что это тривиально реализовать, просто подумал, что уже может быть подходящий метод.
Я бы сделал это универсальным методом вместо взятия object[] хотя ...
@fearofawhackplanet Я не хотел обидеть, но я не знаком с функцией BCL, которая делает то же самое.
@ Aviad, похоже, что нет ни одного, так что вы все равно получите очки ответа :)
Вы по-прежнему собираете бокс, когда вызываете Equals здесь, потому что он будет называть Equals (объект). Мое решение избегает этого.