Так ли нужны операции «&&», «||» и «^^»?В Си-подобных языках принято различать «&&» и «&», «||» и «|», «^^» и «^» («и», «или» и «исключающее или»). Логические операции используют двойные «&&», «||» и «^^», побитовые операции — одинарные.
Возьмём, например, два целых числа, шестнадцатиричные значение которых равно «00000001» и «10000000». Применив к ним логичкую операцию «&&», получаем «истина» && «истина» = «истина». Но применив к ним побитовую «&», получаем: «00000001» & «10000000» = «00000000». Видим, что эти операции не эквивалентны. Похоже, что разное обозначение родственных операций всех устраивает. А зря. Если существует логический тип, у которого «ложь» — это «0», а «истина» — не «0» (~0 == 0xFFFFFF, т.е. «-1» в дополнительном коде), то побитовые «и», «или» и «исключающее или» являются и логическими одновременно. Экономия оперций налицо:
int I, J, K;
I = 0x00FF0077;
J = I & 0x11223344; // результат: 0x00220044
K = J | 0x00110022; // результат: 0x00330066
boolean X = true;
boolean Y = false;
boolean Z = X & Y; // результат: ложь
if ( Z ^ X) // результат: истина
Если сделать так, что оператор «if» принимает только тип boolean,
то запись вида «if X=Y» становится незаконной для X и Y любых типов, кроме boolean.
Чтобы быть правильной, необходимо делать преобразование к boolean: «if boolean(X=Y)».
Это удлинняет запись, но делает очевидными намерения программиста:
int a, b; // ... if (a == b) // нормально if (a = b) // ошибка, если а — не типа boolean if ((boolean) a = b) // требуется преобразование к типу booleanВ логических операций «И» и «ИЛИ» существует один подвох. Дело в том, что они участвуют в ленивых вычислениях. В отличие от побитовых операций. Если первый операнд в операции «И» имеет значение «ложь», а первый операнд операции «ИЛИ» — «истина», то дальнейшие вычисления не производятся. Потому что они бесполезны и уже не могут изменить результата. Но побитовым операциям для вычисления результата второй операнд нужен всегда. Но и это не всё. В C++ вычисление второго операнда для логических операций «И» и «ИЛИ» не производится только для предопределённых типов. Для классов, в которых этих операции переопределены, ленивые вычисления невозможны. Почему? Да потому, что в языке не существует средств, которыми бы можно было описать, который операнд ленивый, а который нет. От таких вопросов невозможно отмахнуться. Если считать этот момент несущественным и производить вычисление операндов всегда, то результатом может быть не только некоторое замедление вычислений. Дело в том, что если операнд не подставляется, а вычисляется, то это вычисление может иметь побочные эффекты. Ну например, если открыть файл, то система с таким вычислением и без него будет находиться в разных состояниях. Но может не всё так трагично, как на первый взгляд? Ведь логические «И» и «ИЛИ» должны, по идее, существовать только для логического типа. Ну может ещё для типов (классов), которые унаследованы от логического Для остальных типов они должны быть побитовыми. Поэтому возможность откладывания вычисления второго операнда нужно оставить только логичесому типу. И типам, для которых логический тип — базовый. Хотя целесообразность создания типов, производных от логического, не очевидна. Так что семь раз отмерь, и только один отрежь... Опубликовано: 2012.09.25, последняя правка: 2021.10.20 22:11
Отзывы
а также False = 0, а True = все остальные значения
В современном стандарте Форт аргументы типа flag (содержащие логическое значение) возвращаемые стандартными словами языка в качестве FALSE должны возвращать одноячеечное число со всеми битами сброшенными в 0, а в качестве TRUE должны возвращать одноячеечное число со всеми битами взведёнными в 1. Так что в знаковом трактовании числа выходит что FALSE = 0, а TRUE = -1. На практике же, повальное большинство слов принимающих аргумент, расцениваемый как логический (не обязательно типа flag, кстати говоря), проводят анализ на равенство именно FALSE и принимают решения исходя из результата этого сравнения, а потому все прочие числовые значения автоматически воспринимаются равными TRUE. Но суть вашего сообщения в корне верна, — в Форт нет логических операций AND, OR, XOR, а также операция сравнения "=" всегда расценивает свои аргументы как числовые, а не логические.
Слова ветвления IF WHILE UNTIL сравнивают аргумент на неравенство нулю и "ответвляются" по данному положению вещей. На деле, при дизассемблировании Форт-кода использующего IF, WHILE и UNTIL, можно видеть что сравнение при ветвлении производится как-раз таки на равенство НУЛЮ.Поэтому де факто True все ненулевые значения. Хотя слова сравнения = <> и др. возвращают True = -1. Для операторов ветвления — согласен, так и есть. Но, например, выражение "1 2 AND" даст в результате 0, хотя и 1 и 2 по сути являют собою ненулевые значения (т.е. могут расцениваться как логическое True). То же самое относится и к операторам сравнения = и <>, ибо, как я уже заметил ранее, в Форт нет логических (булевых) операций. Все (ну или почти все) операции рассматривают свои аргументы как сугубо числовые значения. И потому надо проявлять особую осторожность при составлении выражений смешанного типа.
Как по мне, запись стоˊит унифицировать, но для логических операций предусмотреть "ленивую" и "неленивую" версии. В C это не предусмотрено, в Паскале поведение логических операторов задаётся опциями компилятора, что неудобно. Самый лучший вариант был в VB.NET: в довесок к "ленивым" And и Or имелись "неленивые" AndAlso и OrElse. То же самое можно предусмотреть и здесь: например &, ! -- неленивые операторы (как для целочисленных, так и для логических величин), а &&, !! -- ленивые (только для логических), или наоборот.
Оператора ^^ в C\C++ нет, как ни странно. Есть только ^. Я тоже этому удивлялся.Мне хотелось бы, чтобы все логические операции были «ленивыми». Разница между «ленивыми» и «неленивыми» вычислениями проявляется тогда, когда функция, возвращающая результат, не является чистой, т.е. производит побочные эффекты. Допустим, f(x) возвращает логическое значение и производит побочные эффекты. Тогда bool a = false; if (a & f(x)) // . . .Если «&» — ленива, то f(x) не будет вызвана и не произведёт побочный эффект. Поэтому правильно было бы bool a = false; bool b = f(x); if (a & b) // . . .Для упрощения языка я бы всё-таки оставил бы только одинарные «&», «|» и «^», сделав их ленивыми.
Для упрощения языка я бы всё-таки оставил бы только одинарные «&», «!» и «^», сделав их ленивыми. Программиста, не знающего какие функции у него производят побочные эффекты, все равно уже ничто не спасет. А вот насчет замены операций на побитовые я бы не советовал, будет очень весело, если вдруг туда будет записано неверное значение. Да и как насчет битовых полей и типов меньшего размера? Может если(а ! б) — логическое.
Осутствие автоматического приведения целых типов к логическому убережёт от неправильного понимания «if X=Y». Если Y — целое, то правильным будет «if bool(X=Y)». Значение «true» — это всегда -1, т.е. инверсия нуля («false») устанавливает все биты в «1». А инверсия -1 («true») будет равна 0. Явное приведение целых типов с ненулевым значением к логическому типу даст -1, т.е. «true». Если «false» — это 0, а «true» — это -1, то логические и побитовые операции имеют одинаковую аппаратную реализацию. Несовпадение разрядности приводит к неявному приведению к «наибольшему» типу.
Оператора ^^ в C\C++ нет, как ни странно. Есть только ^. Я тоже этому удивлялся. Вообще-то такой оператор есть. :)Называется: != И для булевых типов работает также как ^. Предполагаю, что авторы языков (Си и его производных) предусмотрительно не стали вводить оператор ^^ с абсолютно таким же действием, как у уже имеющегося оператора.
int a = 1; int b = 2;
Но, вообще-то говоря, несмотря на кажущееся удобство (не нужно писать "лишнюю" проверку != 0), я считаю такое неявное приведение [int к bool] всё же недопустимым (как и сделано в Rust — там оператор if требует значение строго типа bool).
Отсутствие автоматического приведения целых типов к логическому убережёт от неправильного понимания «if X=Y». Если Y — целое, то правильным будет «if bool(X=Y)». У меня только один вопрос остается: явное приведение логического типа к логическому же типу (ну так сказать тоже для большей очевидности намерений) будет возможно, т.е. "bool b; ... if bool(b)"?
Ленивость вычислений в Канторе не проблема, в языке с объектами первого класса все операции обобщенные.
Логические операторы — сравнивают значения, а логические операции, их лучше ещё называть битовыми, чтобы не блудить в трех соснах — это всего-лишь навсего двоичная однобитовая арифметика. То есть, если true and true = true, то 1000 and 0001 — это никак не false, это именно = 0. Ноль, а не false. Вы просто вычли число из нуля, по сути. То есть, в десятичном представлении это аналогично тому, как если бы Вы пытались сравнить true and true = true с 12 — 12 = 0, и удивлялись тому, что здесь что-то не то. Логика отдельно, математика отдельно. Битовые операции — это всего-лишь двоичная арифметика, которая отличается от логики ка небо от земли... и лишь обозначение операторов вносит смущение в Ваш разум. Вот реально представьте себе, что одно — это учебник "Формальной логики", а другое — учебник "Арифметики". Вот и всё. Как я уже писал, чтобы это лучше различать, для логики разумнее использовать операторы в виде слов — or, xor, and, not, а для побитовой арифметики знаки — &, |, ^, ~. И все дела. В речи для логики применять или, и, не..., а для битовых операций — сумма, разность, умножение, инверсия. Ну, Вы поняли, я думаю. Тогда не заблудитесь. Опять таки добра и самопросвещения!
О! Теперь я понял Вы как раз то не поняли. Если Вы с чем-то не согласны, то не стоит чужому мнению приписывать некомпетентность. Это очень лёгкое объяснение. Если бы я пошёл по такому лёгкому пути, то предъявил бы сейчас миру кучу Вашу орфографических и синтаксических ошибок в Ваших сообщениях. А потом бы мог поставить знак равенства между Вашими знаниями в области естественных и искусственных языков.По теме: я лишь захотел съэкономить на знаках операций. К этому имеются предпосылки в языках со статической типизацией. Если в языке логический тип отличен от целого, если нет автоматического приведения целого к логическому (например, в Си if (0)ноль автоматически приводится к логическому типу и равен false), то возможна перегрузка операций «и», «или», «исключающее или». Эти операции, будучи применёнными к значениям логического типа, выполняли бы логические операции. При применении к значениям целого типа, они бы выполняли побитовые операции. То есть одинаковые знаки операций работали бы по-разному с разными типами данных. Но потом Владислав Джавадов указал мне на то, чему я поначалу не придал значения. У логических и побитовых операций разный приоритет, что может создавать неудобства. Я с этим согласился. В принципе, вопрос можно считать закрытым. Но статья осталась на сайте, как напоминание, что такая идея в принципе существует.
НО! Раз Вы занимаетесь разработкой языка, то надо бы как-то по-другому подойти к организации сайта. Если Вы по какому-то вопросу решили сменить свою позицию, то несоответствующие идеи должны перемещаться в архив или каким-либо явным образом помечаться "БОЛЕЕ НЕ АКТУАЛЬНО" или "ИДЕЯ ОТКЛОНЕНА", чтобы вновь прибывающим на Ваш пароход было понятно — на каком этапе у Вас проект, к чему пришли, а что осталось. Я думаю Вы согласитесь, что это было бы разумно, и сЪэкономило бы другим нервы, а Вам время и не пришлось бы разжевывать каждому — что именно Вы имели в виду. И по поводу Ваших придирок к моей грамоте и орфографии... да будет Вам известно, даже великие знатоки языка, будучи профессиональными писателями, отдают свои тексты на дополнительную проверку и редактуру специальным людям, которые как раз и занимаются тем, что осматривают текст на предмет этих самых ошибок. А здесь, в комментариях, да ещё под статьями в которых куча банальных опечаток, я лично не вижу смысла вылизывать текст, только бы Вам понравиться. Здесь главное — взаимопонимание по сути, и для этого моего уровня грамотности более чем достаточно. Если Вас смущают мои системные нарушения в области нервной деятельности, то уж простите — была сложная жизнь, иногда и память подводит, и мозги тупят — тут уже ничего не поделаешь, просто приходится компенсировать другими нейронными системами. Можете считать меня инвалидом, если Вам так будет легче. Но должен Вам заявить, что я и в школьные годы не любил и не понимал языков с их неразумными "правилами" и исключениями. Не понимал и презирал за глупость, поэтому никогда не учил. По ним у меня всегда были четверки и это были единственные предметы, по которым у меня даже частенько проскакивали тройки, при этом я даже по этому поводу никогда не заморачивался, потому что никогда не считал "пишы жы шы с буквой и" — наукой. Ближе к старости в области языкознания я случайно стал увлекаться компаративистикой и потому мое отношение к подобным глупостям только усугубилось, но благодаря различным системам автоматической проверки я все-таки стараюсь писать более принятым образом, хотя и по сей день не считаю это главенствующим и ни к чьей грамотности никогда не придираюсь. Да и не считаю её мерилом интеллекта человека и уж тем более его разумности. В общем, я думаю, что если Вы серьезно относитесь к своему же собственному проекту, то Вам его нужно немного реорганизовать. За десятилетие существования сайта, думаю это сделать можно. Выделить те концепции, которые на данный момент актуальны, старые статьи удалить в архив для хранения объяснений и выводов, новые переписать в виде новых статей по конкретным темам — тогда всем все сразу будет понятно. Вот у меня, например — нет такого сайта. Я все делаю скрытно — сам в себе. Но даже у меня есть книга по моему языку, которая изначально пишется в виде популярного и подробного объяснения концепций языка и его синтаксиса. И вот эта книга постоянно обновляется. Даже читая Ваш сайт я уже придумал и нашел целый ряд идей, которыми улучшил синтаксис Cup-а, и сразу же внес изменения, чтобы на глазах всегда была свежая версия. А если все смешать в одну кучу — и коней и людей, то чему тогда удивляться? Вот такое у меня предложение.
bool a, b, cНадо было сразу проиллюстрировать таким примером. На этом сайте все материалы — стадии «проработка». Когда она закончится, тогда новый язык получит своё название, будет зарегистрировано доменное имя с таким именем. На этом сайте будет только актуальная документация и не будет черновиков. Ну а за этим сайтом, на котором Вы находитесь, оставляю право обладать несовершенством.
a&b <= c^d or a&c > b|d and a&d != b&cВы получите a&b <= c^d | a&c > b|d & a&d != b&cи сиди ломай глаза — где тут что и что к чему... А смысл? Ради потери 4 зарезервированных слов для логики? Сокращение базовых элементов языка должно быть разумным — не в нарушение других принципов языка.
Кто сказал "глупо и непонятно" ? Тьфу на вас! Так все современные языки устроены ))
число << 4; // исчезают 4 левых битато при циклическом сдвиге биты не исчезают, а появляются с обратной стороны число <<< 4; // «вращение» на 4 бита влевоВаша ирония вполне понятна. Но с другой стороны, как ещё обозначить проверку тождества и циклические сдвиги? Можно, конечно, какой-нибудь функцией с традиционным именем типа «is identical». Но существует стиль языка Си, который Евгений Александрович Зуев метко назвал «птичьим»: в нём свист вместо слов. И тем, кто привык к этому стилю, в котором есть своеобразное очарование, легко запомнить новые обозначения с дополнительным символом: «+=», «*=», «&&» и т. д. Языки этого стиля, если просуммировать их общую долю в рейтингах, захватили абсолютное большинство: Си, C++, Java. C#, Javascript, Котлин, Go, Rust, D, Swift, Objective-C, PHP, Perl, Lua, Dart. Так что Вы правы: Так все современные языки устроены Один знакомый начинающий программист, который изучал PHP, однажды увидел текст на Javascript: «О, да тут всё почти одинаково!»
Например, "====" — сравнение с запретом преобразования типов и запретом выдачи предупреждения в этом месте Плюсы и минусы ввода новых символов зависят от метода программирования. Но т.к. Вы исповедуете только метод масштабирования, то здесь соображение такое: новый символ дает возможность инкапсуляции некоторой абстракции, о которой забыли при изобретении изначального языка. Не "я не могу написать программу для этого", а "я не могу написать подпрограмму для заведомого решения всех подобных случаев".
Один знакомый начинающий программист, который изучал PHP, однажды увидел текст на Javascript: «О, да тут всё почти одинаково!» Анекдот времён СССР:Прочитал газету «Правда» и узнал, что написано в остальных газетах.
Присваивание не должно иметь никакого «возвращаемого» значения. Например, в x86 я могу присваивание x=y; реализовать как «push y» и «pop x» Где здесь «значение» В Си возвращаемое значение возвращается в аккумуляторе. Т.е. любое помещение чего-то в аккумулятор "возвращает значение".
А здесь могут получаться лишние и бессмысленные команды. Наоборот, не требуется никаких команд, т.к. в любом месте прервись, а в аккумуляторе что-то есть. Проблема только в том, что Си — это компилятор для быдло-метода, а Вы мыслите категориями пост-Си — методом масштабирования.
put (a = b);Но за этим, конечно, скрываются некоторые подводные камни.
&& — не требуется. Если нужно обязательно вычислить все выражения условия, то именно в этом случае сначала отдельными операторами их вычислить, запомнить результаты в виде логических переменных и эти переменные уже помещать в условие. Это удлиняет программу и усложняет в том плане, что за деревьями уже становится не видно леса.
если хочешь — получи его бесплатно как раз в случае реализации присваивания через push y + pop x не бесплатно, а специально для этого добавляемой командой, которая часто (а в наших программах всегда) не нужна.Это удлиняет программу и усложняет в том плане, что за деревьями уже становится не видно леса. В моей практике я не могу вспомнить случая, когда мне нужно было обязательно считать все выражения условия, хотя условие уже выполнено (или не выполнено). Так, что удлинение программы — в редких случаях, зато & вместо && всегда ))
Раздельные операции [«&» и «&&», «|» и «||» и т.д.] нужны для избавления от скобок. То есть у «&» один приоритет, а у «&&» — другой, побитовая «и» исполнится раньше, чем логическая. За счёт этого можно избавиться от лишних скобок.
a = 1; b = 2;равнозначно если «истина» и «истина»что в итоге «истина». Если же if (a & b)то побитое «и» операндов 1 и 2 дадут 0, то есть это будет «ложь». Это не совпадает с результатом a && b. Вот одна из главных причин, почему в Си-подобных языках операции «&» и «&&» — это отдельные операции.
if (a && b)... if (a & b) А все от того, что кто-то путает язык операторов и язык выражений. Более того, быдло-метод — с методом масштабирования. Машинный язык — с языком Си++-абстракций. Так Вы "откроете", что сложив два больших положительных числа можно получить отрицательное...
недостойный технических дискуссий Быдло-метод — это, может и непривычно звучит, но точно отображает способ программирования: сохраняя навязанные текущей системой ограничения и по-максимуму используя её библиотеки и интерфейсы. Например, так было создано большинство UNIX-утилит, которые делали ровно то, что надо, и добавлялись в ОС сразу, как начинали хоть как-то функционировать.
операции «&» и «&&» — это отдельные операции С моей точки зрения — потенциальный источник недоразумений и ошибок.Я всех заставил писать, что-то вроде: dcl x bit(8); И длиннее и команд больше, зато ясно сказано, что именно проверяется. А на несколько лишних букв и тактов плевать: в случае ошибки гораздо больше сил и времени затрачивается.
Наоборот, не требуется никаких команд, т.к. в любом месте прервись, а в аккумуляторе что-то есть. Это выполнялось для архитектур типа PDP-11 и БЭСМ-6.А, например, в x86 оператор x+=1; удобнее реализовывать одной командой как inc x. И никакого аккумулятора не используется. Впрочем, при разработке x86 (примерно 1977) имели ввиду не Си, а PL/1 ))
Я всех заставил писать Тогда проще без if-oв. Собрать все "управление" в одну шкалу Состояние и честно вычислять смещение программного курсора.
Тогда проще без if-oв Зачем такие крайности? Условный оператор всеми легко воспринимается. Приведенный же мною пример, во-первых, яснее выражает замысел: "я именно хочу проверить, что два старших бита сброшены" и прямо так и пишу. А, во-вторых, демонстрирует одинаковость "битовых" и "логических" операций, если в языке явно есть битовые строки. Есть только "битовые", а "логические" — частный случай "битовых"
Условный оператор всеми легко воспринимается. Точнее, его все считают волшебным. А, на самом деле, трудно найти два языка, где он работает одинаково.Написать автору можно на электронную почту |
2013/11/16 13:05, Noname