Кто-нибудь использует именованные логические операторы? - PullRequest
13 голосов
/ 09 июля 2009

Или мы все придерживаемся нашего учения "&&, ||,!" способ

Есть мысли, почему мы должны использовать один или другой?

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

Ответы [ 13 ]

19 голосов
/ 09 июля 2009

Мне нравится идея оператора not, потому что он более заметен, чем оператор !. Например:

if (!foo.bar()) { ... }

if (not foo.bar()) { ... }

Я полагаю, что второй виден и читаем. Я не думаю, что один и тот же аргумент обязательно относится к формам and и or, однако.

9 голосов
/ 09 июля 2009

"Что в имени? То, что мы называем &&, || или! Любое другое имя будет пахнуть как сладкое. "

Другими словами, естественное зависит от того, к чему вы привыкли.

7 голосов
/ 09 июля 2009

Одна проблема с их использованием (для меня в любом случае) заключается в том, что в MSVC вы должны включить iso646.h или использовать (в основном неиспользуемый) ключ / Za.

Основная проблема, с которой я столкнулся, - это Catch-22, который они обычно не используют, поэтому они требуют, чтобы мой мозг активно обрабатывал смысл, когда старомодные операторы более или менее укоренились (вроде как разница между чтением изученного языка и вашего родного языка).

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

if ((x not_eq y) and (y == z) or (z <= something)) {...}

когда мне кажется, они должны иметь альтернативные токены для всех (хотя бы для сравнения) операторов:

if ((x not_eq y) and (y eq z) or (z lt_eq something)) {...}

Это связано с тем, что причина, по которой были предоставлены альтернативные ключевые слова (и орграфы и триграфы), заключалась не в том, чтобы сделать выражения более читабельными, - потому что исторически были (и, возможно, все еще существуют) клавиатуры и / или кодовые страницы в некоторых местах, которые не имеют определенных знаков препинания. Например, в инвариантной части кодовой страницы ISO 646 (неожиданно) отсутствуют символы '|', '^' и '~' среди других.

7 голосов
/ 09 июля 2009

Те не были поддержаны в старые времена. И даже сейчас вам нужно дать специальное переключение некоторым компиляторам, чтобы включить эти ключевые слова. Это, вероятно, потому, что старая база кода могла иметь некоторые функции || переменные с именами "и" "или" "не".

5 голосов
/ 09 июля 2009

Хотя я довольно давно программировал на C ++, я не знал, что ключевые слова «и» или «и» не разрешены, и я никогда не видел, чтобы они использовались.

Я перебрал свою книгу по C ++ и обнаружил небольшой раздел, в котором упоминается альтернативное представление для нормальных операторов "&&", "||" и «!», где объясняются те, которые доступны для людей с нестандартными клавиатурами, у которых нет «&! |» символы.

Немного похоже на триграфы в C.

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

3 голосов
/ 09 июля 2009

Хотел бы я использовать || и && в обычной речи. Люди очень стараются не понять, когда я говорю «и» или «или» ...

3 голосов
/ 09 июля 2009

Операторы орграфа и триграфа были на самом деле больше предназначены для систем, которые не имеют стандартного набора символов ASCII, таких как мэйнфреймы IBM (в которых используется EBCDIC). В древние времена механических принтеров существовала такая вещь, как «цепочка из 48 символов», которая, как следует из названия, содержала только 48 символов. A-Z (заглавные буквы), 0-9 и несколько символов. Поскольку один из пропущенных символов был подчеркиванием (которое отображается как пробел), это может сделать работу с такими языками, как C и PL / 1, очень интересным занятием (это 2 слова или одно слово с подчеркиванием ???).

Обычный C / C ++ кодируется с символами, а не с орграфами. Хотя мне было известно, что #define «NOT», так как это делает значение логического выражения более очевидным, и визуально сложнее пропустить, чем тощее маленькое «!».

2 голосов
/ 07 сентября 2018

Использование этих операторов вредно. Обратите внимание, что and и or являются логическими операторами, тогда как похожий xor является побитовым оператором. Таким образом, аргументы and и or нормализуются к 0 и 1, а аргументы xor - нет.

Вообразите что-то вроде

    char *p, *q; // Set somehow
    if(p and q) { ... } // Both non-NULL
    if(p or q) { ... } // At least one non-NULL
    if(p xor q) { ... } // Exactly one non-NULL

Bzzzt, у вас есть ошибка . В последнем случае вы проверяете, отличается ли хотя бы один из битов в указателях, что, вероятно, не то, что вы думали делать, потому что тогда вы написали бы p != q.

Этот пример не является гипотетическим. Однажды я работал вместе со студентом, и он любил этих грамотных операторов. Его код время от времени терпел неудачу по причинам, которые он не мог объяснить. Когда он спросил меня, я мог сосредоточиться на проблеме, потому что знал, что в C ++ нет логического оператора xor, и эта строка показалась мне очень странной.

Кстати, способ написания логического xor в C ++ -

!a != !b
2 голосов
/ 09 июля 2009

Приятно использовать их в Eclipse + gcc, так как они выделены. Но затем код не компилируется с некоторыми компиляторами: - (

2 голосов
/ 09 июля 2009

В тех случаях, когда я программирую с именами, напрямую сопоставленными с реальным миром, я склонен использовать 'и' и 'или', например:

if(isMale or isBoy and age < 40){}
...