0xDEADBEEF,
> E> Не лентяи программисты предпочитают определять всего один оператор '<'. А затем через него выводить и равенство, и неравенство и т.д.
> Неправда. Лентяи не знают что через '<' можно вывести равенство .
Более того, нелентяи знают, что есть разница между отношением эквивалентности, устанавливаемым двумя вызовами <, и равенством/неравенством, устанавливаемыми одним вызовом ==/!=.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
>> Неправда. Лентяи не знают что через '<' можно вывести равенство .
ПК>Более того, нелентяи знают, что есть разница между отношением эквивалентности, устанавливаемым двумя вызовами <, и равенством/неравенством, устанавливаемыми одним вызовом ==/!=.
Ну-ка, ну-ка, с этого места и поподробнее. В чем же будет разница между отношениями эквивалентности и порядка при следующих условиях: если (a < b), то (a != b); если (b < a), то (a != b); ? Естественно, подразумевается что отношения эквивалентности коммутативны, а отношения порядка — нет.
__________
16.There is no cause so right that one cannot find a fool following it.
0xDEADBEEF,
> ПК>Более того, нелентяи знают, что есть разница между отношением эквивалентности, устанавливаемым двумя вызовами <, и равенством/неравенством, устанавливаемыми одним вызовом ==/!=.
> Ну-ка, ну-ка, с этого места и поподробнее.
Если есть некоторый предикат, задающий порядок, то далеко не обязательно из (a < b) == false && (b < a) == false следует (a == b) == true. Например, предикат, задающий case insensitive упорядочивание строк при case sensitive сравнении. И наоборот. Допустим, для некоторого класса чисел с плавающей точкой операция сравнения работает с учетом epsilon. В этом случае для двух очень близких чисел (с разницей в пределах epsilon) второе условие будет верно, а первое — нет.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Hello, Павел!
You wrote in conference rsdn.philosophy on Mon, 27 Jun 2005 21:23:45 GMT:
ПК> 0xDEADBEEF,
ПК>>> Более того, нелентяи знают, что есть разница между отношением эквивалентности, устанавливаемым двумя вызовами <, и ПК>>> равенством/неравенством, устанавливаемыми одним вызовом ==/!=.
ПК>> Ну-ка, ну-ка, с этого места и поподробнее.
ПК> Если есть некоторый предикат, задающий порядок, то далеко не обязательно из ПК> (a < b) == false && (b < a) == false следует (a == b) == true.
Это так в текущем стандарте STL. Там понятия эквивалентности и порядка не связаны.
То есть, формально ты прав.
Впрочем, остается еще один вопрос: Ist das gut? В смысле хорошо ли есть такое размежевание с математическими понятиями порядка и эквивалентности?
ЗЫ. В какой-то книжке (уж не Design & Evoloution of C++?) я читал по поводу стандартизации упорядоченных контейнеров.
Там приводились дискусии о критериях упорядочивания. Рассматривались предикаты 'bool operator<' и 'int compare(rhs)' аналогичный strcmp(). А вот rationale почему остановились на том на чем остановились я, увы, не помню.
Posted via RSDN NNTP Server 1.9
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, qxWork, Вы писали:
X>>Более того, первый вариант еще и в общем случае быстрее работает W>ровно на 1 такт ))
Не фига.
1. Первый вариант в общем работает столько же, сколько и второй. Отрицание в самом операторе не реализуется машинной командой отрицания.
2. Второй вариант может сработать быстрее ровно на 1 такт. Если проверка первого значения сразу даст true, а компилятор работает с настройкой быстрого вычисления булевских выражений.
СГ>if( (pointer != null) && (используем выражения с pointer зная что он точно не null) )
СГ>
СГ>
СГ>if( (array != null) && (array.Length >= N) && (используем выражения с array зная что он точно не null и что его длина точно >= N) )
СГ>
СГ>не превращать "тождественными" преобразованиями ни во что другое. Проверка выражений идет слева на право и если на каком-то шаге результат становится известным, то дальнейшая проверка "хвоста" не осуществляется.
Можно очень, очень, очень не хорошо попасть с настройками компилятора.
Здравствуйте, SiAVoL, Вы писали:
SAV>Ведущие собаковеды рекомендуют не использовать много отрицаний в условиях и уменьшать их, используя теоремы Моргана SAV>Т.е. например код SAV>
SAV>ИМХО, первый вариант несколько более читаем — не равно нул и не равно строке "test". Все ясно и понятно. Смысл же второго (по крайней мере мне) уже не так очевиден. SAV>Понятно, что когда условие сложное, то большое количество отрицаний реально замедляет понимание кода. Но зачастую классики приводят примеры аналогичные моему и говорят, что второй вариант лучше. SAV>Это именно особенности моего восприятия, или классики ошибаются, или я что-то недопонимаю?
Может, речь идёт об операторе "!". Оператор "!=" ничуть не хуже оператора "==". В итоге второй вариант как раз и содержит лишний "!".
Здравствуйте, ukshish, Вы писали:
U>Может, речь идёт об операторе "!". Оператор "!=" ничуть не хуже оператора "==". В итоге второй вариант как раз и содержит лишний "!".
Читать весь форум надо. Уже в самой первой ветке было сказано, что пример супер неудачный, а автор неправильно понял рекомендации
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Я бы рекомендовал код типа таких: СГ>
СГ>if( (pointer != null) && (используем выражения с pointer зная что он точно не null) )
СГ>
СГ>
СГ>if( (array != null) && (array.Length >= N) && (используем выражения с array зная что он точно не null и что его длина точно >= N) )
СГ>
СГ>не превращать "тождественными" преобразованиями ни во что другое. Проверка выражений идет слева на право и если на каком-то шаге результат становится известным, то дальнейшая проверка "хвоста" не осуществляется.
помнится в свое время я был сильно удивлен, что в IB это не так
.
))
