&& = и || = операторы

Question

Возможные Дубликаты:
Why doesn't Java have compound assignment versions of the conditional-and and conditional-or operators? (&&=, ||=)
Why does a “&&=” Operator not exist?

Сегодня на работе я написал следующее LOC (реальные тождества б и б1 являются конфиденциальными:)

b &&= b1; // meaning b = b && b1; 

Я смотрел на него на пару секунд и поняли, что такого оператора не существует. Чтобы быть уверенным, я нажал на компиляцию, и это не удалось. Чтобы быть уверенным, я посоветовался со стандартом.

Существуют ли конкретные причины того, что таких операторов нет? Я могу думать о некоторых:

1. b &&= b1 и b = b && b1 не могут быть эквивалентными из-за оценки короткого замыкания & &.
2. & & = некрасиво
3. & & = редко требуется

Я не утверждаю, что это было бы очень полезно иметь такие операторы, нет. Я также не утверждаю, что никаких или всех из трех вышеуказанных причин недостаточно, чтобы воздержаться от создания этого оператора. Мой вопрос заключается в следующем: может быть, есть гораздо более серьезная причина, над которой я наблюдаю?

Answer 1

Я не знаю, почему и вопрос, и некоторые из ответов говорят о коротком замыкании поведения соответствующих логических операторов в качестве потенциальной проблемы.

Существует абсолютно никаких проблем с коротким замыканием при определении &&= и ||= операторов. Они должны быть определены равномерно с += и другими аналогичными операторами, что означает, что a &&= b должен быть эквивалентен a = a && b, но с a оценивается только один раз в версии &&=. Это, в свою очередь, означает, что b не оценивается вообще, если a изначально равен нулю. Легко.

Таким образом, единственная причина, по которой они не существуют на этом языке, - это «просто потому, что».

Answer 2

EDIT: Неправильный язык, но до сих пор применяется

Я согласен с вашими тремя причинами, хотя есть один сценарий, в котором я посетовал на отсутствие этого оператора, при написании пользовательских десериализации процедур. В нескольких случаях, когда неправильно сериализованный объект не был действительно «исключительным» (и чтобы исключить накладные расходы на C# для очень распространенных сбоев), я бы использовал логические значения возврата, чтобы показать, была ли операция десериализации успешной.

Этот код полностью теоретический и Nested1, Nested2 и Nested3 все: Структуры

public struct ComplexStruct 
{ 
    private Nested1 nested1; 
    private Nested2 nested2; 
    private Nested3[] nested3; 

    public bool Read(Reader reader) 
    { 
     bool ret = true; 
     int nested3Length = 0; 

     ret &&= nested1.Read(reader); 
     ret &&= nested2.Read(reader); 
     ret &&= reader.ReadInt32(ref nested3Length); 

     for(int i = 0; (ret && i < nested3Length); i++) 
     { 
      ret &&= nested3[i].Read(reader); 
     } 

     return ret; 
    } 
} 

Answer 3

Я хотел их до того, как хорошо. Я сомневаюсь, что уродство было само по себе определяющим фактором, короткое замыкание - лучший аргумент против них, который я слышал до сих пор.

Еще одним фактором, способствующим тому, что C предназначен для работы вблизи металла, в значительной степени все операторы соответствуют инструкциям в основных архитектурах. Я не думаю, что есть инструкция по x86, PPC и т. Д., Которые непосредственно реализуют b &&= b1;

Answer 4

Лично я проголосовал за первое обоснование, с которым вы пошли. Булевы операторы имеют короткозамкнутую семантику, которая могла бы привести к некоторым действительно грубым ситуациям, если они переведены в операторы присваивания. Либо вы больше не делаете их короткозамкнутым, либо создали какой-то странный «необязательный» оператор присваивания (делайте вещи справа и присваивайте результат, только если значение на LHS уже отличное от нуля). В любом случае вы создадите тонкие ошибки, потому что люди будут ожидать другого поведения.

Answer 5

Основная причина, по которой операторы не существуют, вероятно, состоит в том, что K & R не думал ни о каком привлекательном способе их определения. Мне также иногда нужен оператор -> = (ptr -> = next будет эквивалентен ptr = ptr-> независимо).

проблема, я думаю, что с & & = является то, что это не очевидно, что из перечисленного будет наиболее полезным, или которые он должен быть:

 
    if (lhs && rhs) lhs = 1; else lhs = 0; 
    if (!rhs) lhs = 0; else lhs = !(!lhs)); 
    if (lhs && !rhs) lhs = 0; 
    if (!rhs) lhs = 0; 

Первый вариант является одним из наиболее четко предложил синтаксисом, но из практическая точка зрения, если ни один из них не равен нулю, часто было бы более полезно оставить левую сторону в одиночку, чем установить ее в «1».

BTW, я часто хотел, чтобы вариация оператора запятой оценивала левую сторону, сохраняла значение, затем оценивала правую сторону и возвращала значение левой стороны. Эквивалент:

 
int foo(int p1, int p2) return p1; 

, за исключением применимого к любому типу (p2 не обязательно должен быть того же типа, что и p1, и может быть недействительным) и с гарантированным порядком оценки слева направо. Было бы очень удобно для таких вещей, как индексирование после инкремента с помощью не единичного шага, например arr [ptr ~, ptr + = 2]; или для определенных типов операций обмена данными, например var1 = (var2 ~, var2 = var1); и т. д.

Answer 6

Поскольку результат a && b всегда 0 или 1, я думаю, что интерпретация этого будет только однозначной для типа C99 _Bool. Поскольку этого не существовало в момент создания C, этот оператор тогда не включался. И в настоящее время никто не может добавить другого оператора в C, поскольку это повлияет на все существующие синтаксические анализаторы.