If-ы и состояния

[Scorp__)]

Как это у нас частенько бывает, из одной темы родилась другая. Итак, начало здесь:

https://forum.shelek.ru/index.php/topic,1010.msg146194.html#msg146194


PooH, вообще это будет странно. Особенно если учесть, что BOOL изначально не было, и если ноль, то была ложь, а если нет, то истина. А вот как сюда впихнуть третье состояние... Совместимость же должна быть с Сишными программами.

[Гром]

Для железа есть три состояния, а не два.
Соответственно уровень напряжения, что то вроде 1.5в - значение 0, 5.5в - значение 1 - а вот третье называется тристейт, ни то ни се - напругу не поняю к сожалению...

[Pu]

для разных видов микрух в тех характеристиках свои напряжения логических уровней. во всяком случае КМОП по этим характеристикам достаточно отличается от ТТЛ логики.

[Scorp__)]

Гром, ну для каждой логики разное напряжение... А для Z-состояния как я понимаю и нету напряжения, там же просто высокое выходное сопротивление. То есть грубо говоря нога работает как вход.
Но мы-то говорим о значении переменной, если даже где-то в железке памяти будет Z-состояние. То в значении хранимой переменной все равно получится число, хоть мы его и не сможем считать.

Pu, а ЭСЛ сильно отличается от них обеих

[RXL]

В Perl, кстати, давно есть специальное состояние - undef. Т.е. значение может быть как неопределенным, так и определенным.

В JavaScript - два дополнительных состояния: undefined и null.

Примерчик возможной проверки логической переменной на PHP:

Код:

if (isset($var))
{
}
elseif ($var)
{
}
else
{
}

[Антон (LogRus)]

Для С++ есть QNAN
при определённом значении double не равен самому себе искать в numeric_limits

есть еще boost::optional
а также есть шаблоны с помшью которых прекрасно создаётся обёртка для подлючения состояния null/undef/valid к уже существующим типам/классам

кстати Студийный BOOL позволяет хранить несколько состояний
кроме того можно bool интерпретировать как int
bool b;
if(*reinterpret_cast<int*>(&b) == -1)
  throw exception("undef");

[Антон (LogRus)]

Вот еще полезная вещь
http://www.boost.org/doc/html/tribool/tutorial.html
bool с кучей состояний
но нет сишной совместимости
я бы выбрал или short/int/long(скорее long) + enum/define или POD структуру {bool state_; bool isDef_;}

[Pu]

да, с чего все начиналось

понравилось на башорге

<gram|work> про индийский код
<gram|work> Какой самый извращенный способ проверить в условии if () булевскую переменную ?
<gram|work> bool b;
<gram|work> b = false;
<gram|work> if (b == true){...}
<gram|work> Это децкий лепет
<gram|work> ИТАК, ПЕРВОЕ МЕСТО
<gram|work> Знакомый говорит что нашел только что в коде:
<gram|work> if (b.ToString().length < 5){...}

[Pu]

лично для меня тип bool не имеет особо ценного значения , я всегда скорее проверку веду в if по принципу if(!b), if(b), if(b<0) итд. подразумевая что в качестве b может быть любой тип аля int.

[Джон]

Нв самом деле всё гораздо проще. Если, конечно, посмотреть на вещи серьёзно.
1. Железо. Хоть мы и говорим о "цифре" - это всё-таки аналоговые вещи. Те на вход можноподавать ЛЮБОЕ напряжение. Поэтому для них установлены стандарты. Те, если ты хочешь установить "уровень напряжения логической единицы", то ОБЯЗАН позаботится о том, чтобы для ТТЛ это напряжение было выше 2,5 вольт. Соответственно для нуля <0,5 вольт. При промежуточных напряжениях 0,5<U<2,5 выход ИС будет находится в неопределённом состоянии, те там будет либо 0, либо 1 - зависит например от температуры, напряжения питания ИС и тд и тп. Для KMOП и эмиттерносвязанной логики существуют свои стандарты. Так же это ещё зависит и от качества изготовления ИС. В "древние" времена произовдились ИС для ширпотреба и на "войну". У последних параметры были значительно лучше (допуски, температурный режим и тд) и точнее.

2. Программирование
Пример: у объекта есть некий флажок (true/false), который пользователь может изменять. Но для него есть ещё и дефолтное значение, установленное, например, при инсталляции проги. Те мне необходимо различать состояния

true/false - установленные пользовательем
true/false - установленные при инсталляции

Конечно можно (и ИМХО) лучше взять для этих целей enum, но кто мешает сделать некий объект, который ведёт себя как bool, только при этом ещё проверяет 3 состояние - пользователь не определял значение флажка, значит при запросе получит дефолтное значение.

Но речь идёт (вернее шла в "хи-хи") не о железе и особых случаях, а о простой проверке булевой переменной.

[Dimka]

В .NET 2.0, где появились nullable-типов, можно вводить третье состояние для логики:

Код: (Text)

bool? a;

a = true;
a = false;
a = null;

// При различении третьего состояния.
if(a == null) { ... }
else if(a) { ... } else { ... }

// При неразличении третьего состояния.
if(a ?? false) { ... } else { ... }

[Джон]

// При различении третьего состояния.
if(a == null) { ... }
else if(a) { ... } else { ... }

Именно это я и имел ввиду. Плюс ещё в том (я такое использовал не для логики, а для цвета), если например дефолтные значения поменялись, то все объекты с ними можно обновить, оставляя при этом изменения пользователя нетронутыми, если таковые были сделаны.

[Гром]

Я приводил к железу только дабы показать нгеобязательную дуальность даже машинной логики. С/С++ в данном случае тривиален и слаб.

Тип булеан на деле опреден как ubsigned int и даст true при любом значении отличном от 0. Что сугубо ошибочно, ведь не проинициализированная переменная примет любое значение неочищенной памяти, где она была выделена, что при маленькой ошибке может кончится рухнувшей программой решившей, что у нее есть в наличии оборудование, которого просто нет и оно непроинициализировано.

Во вторых конструкция if еще более порочна. Она проверяет на нулевое значение даже строковые переменные воспринимая их как беззнаковое целое размером с 1 байт. Т.е. если у меня есть
char a = '0';
То проверка на if (a) даст мне TRUE, что по идее противоречит, ведь символ 0 вписан в переменную текстового типа и по идее FALSE!!!

Таким образом не зная типа переменной проверямой в if() лучше действительно писать
if (a == TRUE) так как в этом случае ошибка выпадет еще при компиляции....

Кстати наталкивался на такие случаи в практике. Когда полаешь переменную типа unsigned int в виде флага, но проверяшь стандартно if (var) когда наткнулся на проблему с тем, что флаг был не дуальный, а описывался enum из трех или четырех значений, что было от меня скрыто в библиотеки чужого кода.

Но вышенаписаный пример - просто смешен когда имеешь дело со стандартными делами.

[Джон]

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

В С++ есть ещё и bool, использовать который предпочтительней. BOOL введён МС для ускорения работы с растущими целыми типами. В С++ они зависят от разрядности машины. Тут уж как говориться, кому что.

Насчёт символа эт ты погорячился. Ты же вписываешь не 0х0, а 0х30. Ведь char это тоже целый тип - знаковый байт.

Вот так будет работать.

char a = '\0';
if (a)...

Про остальное - надёжней всего проверять так.

if (a&TRUE == TRUE)

[Dimka]

Про остальное - надёжней всего проверять так.
if (a&TRUE == TRUE)

С точки зрения устойчивости это ничем не отличается от if(a) для случая, когда a не инициализировано - всё равно результат будет случайным. В этом смысле мудры MS компиляторы .NET-языков - они просто выдают ошибки компиляции, если: есть непроинициализированные переменные, не по всем веткам условий функция достигает своего оператора(ов) return и т.д.

[Джон]

Когда не иницаллизировано - согласен. Тогда уже ничто не поможет. Но во всех остальных случаях - надёжней, чем if(a)

зы конечно TRUE это только для примера - имеется ввиду любая искомая величина.

[Dimka]

Но во всех остальных случаях - надёжней, чем if(a)

Чем? Если а - не bool, не вижу никакого смысла проверять отдельные биты. Допустим TRUE=1, а=0,1,2,3..., тогда в результате a&TRUE==TRUE будет последовательность false,true,false,true,... тогда как при if(a) будет false,true,true,true,... Аналогично, если TRUE=11...1b - все будут false кроме самого меньшего знакового или самого большего беззнакового для данной разрядности.

Ошибка-то семантическая, а не синтаксическая. Если мы ждём bool, а поступает не bool, то любой результат ошибочен - поведение программы становится непредсказуемым. Если же гарантированно поступает bool, то нет никакого смысла явно сравнивать его с TRUE.

[Джон]

нуууу эт как сказать. Возьми пример Грома.

char a = '1';

 или

char a[] = "1";

if(a)

if(a&TRUE==TRUE)

те в любом случае получится истина - и как указатель и как значение - они больше нуля. Но TRUE (я останусь пока при этом примере) определена как -1, поэтому в любом случае входа в иф не будет и ошибку будет легче найти. Тк при дебаге я вижу, что а = 0x31 (или a=0x0abc1234), а в условие не захожу.
При if(a) я зайду в цикл и даже не задумаюсь об этом. Вот и всё. А если я хороший программист , то я обязательно сделаю ещё и else-блок с кучей ифы типа трассировки.

[Dimka]

А мне так без разницы, в then или в else ветку заходит, если a - не bool. Отчего ветка then предпочтительнее ветки else? А если я напишу if((!a)|FALSE==FALSE), тогда как?

Эти все ухищрения всего лишь сужают диапазон значений true с любого !=0 на конкретный. Более ничего не происходит - ошибка возможна всегда. С некоторой вероятностью a равно -1 (или когда-нибудь a станет -1), и тогда ничего уже не спасёт. Но низкая вероятность не означает определённость. И для тестов только хуже будет: проверяли на Земле спутник какой-нибудь 30000 раз, запустили, а там выпало на 30001 разе.

То есть синтаксически эту проблему не решить иначе, нежели ввести тип bool, не входящий в домен числовых типов. И то не поможет в случае отсутствия инициализации переменной.

[Pu]

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

bool b(false);
int i(0);

etc etc

а если кто делает иначе, ну я нинаю!!! значит низя быть програмистом.
и MS определения типа TRUE FALSE стараюсь не использывать по возможности.

[Джон]

dimka, читай внимательно

Когда не иницаллизировано - согласен.

Так что я не понимаю зачем ты эту тему дальше мусолишь? Кто переменные не инициаллизирует - отправляется в школу в первый класс и решает задачку про Буратино и яблоки.

А если я напишу if((!a)|FALSE==FALSE), тогда как?

Эту уже не ухищрения, а извращения - поэтому был пост Pu в "хи-хи". И написать ты можешь конечно всё, что угодно.

Offtopic:

Кстати, идея - сделать раздел "Кунсткамера", в который таких "уродцев" помещать. У меня уже есть экземплярец - определение текущей системной даты по времени создания файла!

Поставлю в угол.

Отчего ветка then предпочтительнее ветки else?

Ну, а предпочтительней она потому, что в большинстве случаев  по истине отрабатывается "положительные" случаи

if(pObj) { ... }
if(CreateWindow())  { ... }
if(IsIntialized())  { ... }

даже свойство имеет противоположное значение, то делается инверсия

if(!IsEmpty())  { ... }

Код читать/отлаживать/понимать легче. Или ты считаешь, что лучше сначала просмотреть обработку ошибки? Хотя это уже область "А мне нравицца вот так!".

А к "моему" способу могу ещё добавить. Что часто (скрытая) ошибка возникает при использовании именно не булевских типов. Пример, есть некие битовые флажки

byte b1 = 1;
byte b2 = 2;
byte b3 = 4;
byte b4 = 8;

Необходимо проверить эти биты в неком числе Х. Если это byte, то всё замечательно работает:

byte GetXValue() { ...  }

byte X = GetXValue();

if(X&b1) { ... }

но, как только он становится "больше" - WORD, INT и тд, тут то и начинаются проблемы. Особенно учитывая "замечательную" способность С++ автоматически делать кастинг всего и вся.

DWORD GetXValue() { ...  }

DWORD X = GetXValue();

if(X&b1) { ? ? ? }

Если повезёт и старшие биты Х будут обнулены, это сработает. А если нет? Вхождение в условие всё-равно произойдёт тк !=0

if(X&b1==b1) - работает в этом случае надёжней. И вход произойдёт только в том случае, если бит b1 установлен.

[Serg79]

DWORD X = GetXValue();

if(X&b1) { ? ? ? }

Если повезёт и старшие биты Х будут обнулены, это сработает. А если нет? Вхождение в условие всё-равно произойдёт тк !=0н.

Сдесь Джон, Ты ошибаешься. Проблем ни каких не будет. Просто тип char будет расширен до unsigned int (стандартное расширение типа) и результат выполнения операции '&' от этого не измениться.

if(X&b1==b1) - работает в этом случае надёжней. И вход произойдёт только в том случае, если бит b1 установле

Это выражение вообще работать не будет. Т.к. приоритет операции '==' выше чем у операции '&'. Это одно и тоже, что и " x & (b1 == b1) ", как видишь это не совсем то, что нужно.

Вернее работать будет если установлен первый бит, т.к. операция '==' для любых значений b1 будет довать 1.

[Dimka]

Serg79, точно приоритет битовых операций ниже приоритета сравнения? Что приоритет && ниже == - согласен, а вот & - не уверен.

[Dimka]

предпочтительней она потому, что в большинстве случаев  по истине отрабатывается "положительные" случаи

Я не знаю, что такое "положительные" случаи. Если для условия альтернативной ветки не нужно, то, естественно, условие подбирается соответствующее; возможно и if(!IsEmpty()). Если для условия есть обе ветки, то я предпочитаю писать в начале ту, которая короче (если она не длиннее экрана), чтобы видно было, к чему относится else.

Если повезёт и старшие биты Х будут обнулены

В каких случаях не повезёт?

[Джон]

Это выражение вообще работать не будет. Т.к. приоритет операции '==' выше чем у операции '&'.

Согласен, поторопился - возьми первое выражение в скобки.

if((X&b1)==b1) {  }