Письменные версии логических операторов


95

Это единственное место, которое я когда-либо видел and, orи оно notуказано как фактические операторы в C ++. Когда я написал тестовую программу в NetBeans, я получил красное подчеркивание, как если бы произошла синтаксическая ошибка, и решил, что веб-сайт был неправильным, но это NetBeans, который неверен, потому что он скомпилирован и работает, как ожидалось.

Я вижу, !что меня предпочитают, notно удобочитаемость and&& orкажется лучше, чем их грамматические братья. Почему существуют эти версии логических операторов и почему, казалось бы, никто их не использует? Это действительно действительный C ++ или какая-то совместимость с C, который был включен в этот язык?


4
\ me Переписывает весь свой код
Ограниченное искупление

2
в духе «чистого кода» я лично рекомендовал бы избавиться от привычки писать ||и &&, может быть, даже !временами. Слова всегда лучше, чем «линейный шум», не говоря уже о возможной путанице с операторами манипулирования битами.
Ichthyo

2
@Ichthyo Это не всегда правильно. Гораздо быстрее читать много символов и понимать их значение, чем читать много слов.
vallentin

то, что яснее для человеческого читателя, зависит от «гештальта». Иногда символ может быть яснее, чем какой-то запутанный термин, но в данном случае это не так. И простые слова английского языка гораздо более универсальны, чем некоторые странные специальные символы несколько странного языка программирования ...
Ichthyo 03

3
Ирония в том, чтобы сказать, что andэто более читабельно, а затем написать « and&& or» :)
Иван

Ответы:


114

Они возникли в C в заголовке <iso646.h>. В то время были клавиатуры, которые не могли ввести необходимые символы для &&(например), поэтому в заголовке содержались символы #define, которые помогли бы им в этом, (в нашем примере) определяяand как быть &&. Конечно, со временем это стало меньше использоваться.

В C ++ они стали так называемыми альтернативными токенами . Вам не нужно ничего включать, чтобы использовать эти токены в совместимом компиляторе (как таковая, версия заголовка C, связанная с C ++, пуста <ciso646>). Альтернативные жетоны похожи на обычные жетоны, за исключением написания. Таким образом , во время синтаксического анализа andявляется именно такой же , как &&, это просто другой способ правописание то же самое.

Что касается их использования: поскольку они используются редко, их использование часто более удивительно и сбивает с толку, чем полезно. Я уверен , что если бы это было нормально, они были бы гораздо легче читать, но люди так привыкли &&и ||все остальное просто получает отвлекают.

РЕДАКТИРОВАТЬ: Однако с тех пор, как я опубликовал это, я заметил очень небольшое увеличение их использования. Я до сих пор их избегаю.


Итак, интерпретация этих альтернативных токенов - это просто функция компилятора или она содержится в спецификации C ++?
defctivehalt

2
@Kavon: Это указано в разделе 2.5 стандарта; это языковая особенность.
GManNickG 04

15
Я лично считаю, что они намного лучше ... но тогда я предвзято отношусь к Python. Я не знаю, почему некоторые люди думают, что если он не искажен, то это не код ...
Матье М.

Значит, они недействительны в C без включения этого файла заголовка? Я удивлен, что ими пользуются не все; они делают Python более читабельным.
endolith

1
По крайней мере Visual Studio 2015 CTP 6 не понравился мой orили notбез включения заголовка.
usr1234567

19

Они существуют для удобства использования (поддержка символов в вариантах клавиатуры / дисплея) и общей читаемости, но есть еще одна причина, которая в настоящее время более очевидна. Почти нет ответов здесь , здесь , или даже основного ответа здесьобъясните основную причину, по которой многие из нас предпочитают версии слова версиям символов (и основная причина, по которой их используют другие языки): ошибки. Различия между версиями слова очень заметны. Различия между версиями символов заметно меньше, что может привести к появлению ошибок в сравнительно большей степени: «x | y» в значительной степени не является «x || y», но когда оно встроено в более крупное выражение, многие из нас упустите разницу. Это похоже на обычное случайное смешивание оператора присваивания и равенства. По этой причине я отказался от версий символов (это было непросто) в пользу версий слов. Из-за нашей любви к старым я бы предпочел, чтобы кто-то их обидел, чем искушал ошибки.


4
К сожалению, в Visual Studio (начиная с VS2013) вы должны установить конкретный параметр компилятора ( /Za), чтобы поддерживать альтернативные ключевые слова (см. Stackoverflow.com/a/555524/368896 ). По-видимому, это имеет и другие последствия. Таким образом, в Visual Studio не обязательно следовать этому совету.
Дэн Ниссенбаум

FWIW / - поскольку я помещаю пробелы вокруг операторов, x | yон достаточно визуально отличается (в моноширинных шрифтах) от x || y, но я считаю, что, !например, if (!f(xyz) && ...проще пропустить, чем if (not f(xyz) && ....
Тони Делрой,

@Tony D, когда вы ставите пробелы вокруг операторов, это ваше личное соглашение и не очевидно для читателя. Но с использованием естественного языка слово , как and, orи notв логическом выражении, на самом деле улучшает читаемость и это подчеркивает различие в битовые манипуляции. Таким образом, ИМХО, мы должны подумать об изменении наших любимых старых привычек к лучшему ...
Ichthyo

@DanNissenbaum Я нашел эту опцию под названием C / C ++> Language> Disable Language Extensions , поэтому ожидать побочных эффектов относительно безопасно;)
Wolf

6
Знаете ли вы, сколько ошибок Python было введено из-за того, что слова andи orпредвзятое мнение людей о том, как они должны работать? Например, if (a == b or c)вместо if (a == b || a == c)- что-то подобное появляется здесь, в StackOverflow, почти каждый день. Абстрактные символы, не связанные с английским языком, уменьшают эти ошибки.
Марк Рэнсом

10

В C ++ это настоящие ключевые слова. В C это макросы, определенные в <iso646.h>. См. Http://web.archive.org/web/20120123073126/http://www.dinkumware.com/manuals/?manual=compleat&page=iso646.html .


6
Технически это альтернативные токены, а не ключевые слова. :)
GManNickG 04

2
@GMan: +1 Хороший звонок, хотя на странице Dinkumware они называются ключевыми словами, так что, полагаю, они не особо заботились о различиях.
Крис Джестер-Янг,

Обновленная ссылка: f3.tiera.ru/1/addesio/computer-science/C&C++/…
kevinarpe

Итак, поддерживает ли MSVC их «из коробки» на C ++, но не на C?
rwst

1
@rwst Я не могу комментировать конкретно MSVC, но если он точно реализует стандарты C ++ и C, то это действительно так. См. Также: stackoverflow.com/questions/2376448/…
Крис Джестер-Янг,

2

andи &&функционально такие же в C ++. andиor операторы действительно действует C ++ и является частью стандарта языка.

Чтобы уточнить другие ответы с бетонным например, есть еще одна причина , кроме просто «читаемости» предпочитают andболее&& . Явное указание «и», когда вы имеете в виду логическое «И», исключает возможность мелких ошибок.

Учти это:

int x = 3;
int y = 4;

// Explicitly use "and"
if (x and y) {
    cout << "and: x and y are both non-zero values" << endl;
}

// Using "&&"
if (x && y) {
    cout << "&&: x and y are both non-zero values" << endl;
}

// Oops! I meant to type "&&"!
if (x & y) {
    cout << "&: x and y are both non-zero values" << endl;
}
else {
    cout << "How did I get here?" << endl;
}

Все три оператора if будут компилироваться, но последний означает нечто совершенно иное и непреднамеренное!

Если вы всегда используете, andкогда имеете в виду логическое И, вы никогда не сможете случайно набрать один «&», и ваш код будет успешно скомпилирован и запустится с загадочными результатами.

Еще одно хорошее упражнение: попробуйте случайно опустить символ «и» и посмотрите, что получится. ;)


1
Это не совсем ответ на вопрос. Просто вы говорите, что, по вашему мнению, более разборчиво. ОП спросил, как работают написанные версии, а не какие из них лучше. И кто-то другой уже высказал то же самое, что и вы.
Никол Болас

Не то чтобы он действительно предоставляет больше полезной информации, но я добавлю « andи &&функционально идентичны» к ответу ... И если вы прочитаете мой ответ, вы увидите, что я говорю НЕ о разборчивости;)
tjwrona1992
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.