Что плохого в явном написании условия в if?

Сообщение от Fulcrum_013 людей которые пишут C++ 1 if (a==0) а тем более C++ 1 if (a==false) вместо C++ 1 if (!a) Умными или адекватными назвать трудно.

Вы не погорячились? что такого плохого в
или
?

0

castorsky, до появления в стандарте bool каждая кучка программистов так или иначе реализовывала этот тип. Кто-то через перечисления, кто-то через число, кто-то через класс. Из-за этого при совместном использовании получалась адская путаница. Для того, чтоб договориться, и был введен bool. Заодно чувачки проанализировали кучу кода С++ и выяснили, что в подавляющем большинстве реализаций bool свободно конвертируется в int и обратно. Поэтому не стали ломать существующую ситуацию и разрешили неявные преобразования.

0

Сообщение от ct0r до появления в стандарте bool каждая кучка программистов так или иначе реализовывала этот тип.

Да.Его даже в C99 добавили.

0

Сообщение от ct0r Поэтому не стали ломать существующую ситуацию и разрешили неявные преобразования.

Это их серии "все пользуются stl давайте добавим ее в стандарт". Никогда в коде не видел искуственного bool и никогда его не делал. Так же как stl пользует восновном нижняя квалификация. Даже у мелкомягких к примеру в семплах DirectX SDK свой лисапет на тему динамических массивов более удобным интерфейсом чем std::vector.
А появился в C++ тип bool когда появились визуальные редакторы. Это единственное его применение - задание диапазонов ручного ввода посредством RTTI.

0

Сообщение от castorsky И типизация тут не при чем.

Очень даже "при чем".

Сообщение от castorsky В теории это разные типы, они не могут быть кастованы неявно.

В теории - могут.

Вот теория:
4/2

(2.2) — When used in the condition of an if statement or iteration statement (6.4, 6.5). The destination type is bool.

4/4

Certain language constructs require that an expression be converted to a Boolean value. An expression e appearing in such a context is said to be contextually converted to bool and is well-formed if and only if the declaration bool t(e); is well-formed, for some invented temporary variable t (8.5).

4.12/1

A prvalue of arithmetic, unscoped enumeration, pointer, or pointer to member type can be converted to a prvalue of type bool.

Вот практика:
http://rextester.com/TISS75398
http://rextester.com/MPKNZQ7125

Добавлено через 7 минут

Сообщение от gazlan C/C++ не требуют здесь bool типа

С++ требует. Смотри цитаты выше.

Сообщение от gazlan Выражение в скобках сравнивается с нулем (типа, test eax,eax / jz).

Конкретная реализация не играет в этом смысле роли.

0

Сообщение от DrOffset В теории - могут

м.б. в каких-то Ваших личных теориях. Я их не знаю.

Сообщение от DrOffset Вот теория

Очень смешно, кэп. Я уже говорил об этом.

Вот наличие булева типа в языке

0

Сообщение от DrOffset С++ требует. Смотри цитаты выше

Я уже приводил пример грамматики. Ваши цитаты ее подтверждают.

0

Сообщение от castorsky Вот наличие булева типа в языке

Это передергивание. Это доказывает только то, что Haskell сильно типизированный язык. Продемонстрировал, что нельзя привести 1 к bool в Haskell? Ну, замечательно. А в С++ можно.

Добавлено через 8 минут

Сообщение от castorsky Я уже говорил об этом.

Если ты об этом:

Сообщение от castorsky а если бы тип bool присутствовал, то этот код не скомпилировался из-за несоответствия типов.

то это не может быть доказательством, т.к. С++ не сильно типизированный язык и разрешает неявные преобразования типов. А то, что такие преобразования происходят, четко прописано в стандарте языка. Ну ладно, стандарт. Фиг с ним. Но вот выше был дан вывод двух компиляторов. Оба почему-то пытаются приводить к bool. Не знаешь почему?

Сообщение от gazlan Ваши цитаты ее подтверждают.

Я против грамматики ничего не имею, она верна и взята из стандарта С++.
Я говорю о том, что if и iteration statements требуют приводимости выражения к bool. Не к int и ни к чему-то другому, а именно к bool. И вот это

Сообщение от gazlan C/C++ не требуют здесь bool типа

идет несколько вразрез с цитатами.

1

Сообщение от DrOffset требуют приводимости выражения к bool

OK.

И вот это ... идет несколько вразрез с цитатами

Простой пример: if (-1 + 1.0)

Укажите, какой из операндов (или выражение в целом) имеет тип bool?

Конверсия (причем, неявная - на платформе, где false есть нуль, компилятор никаких приведений к bool выполнять не будет) возникает именно в момент сравнения результата вычисления выражения с нулем. Что, собственно, и было стартовой точкой.

0

Сообщение от Fulcrum_013 Сообщение от ValeryS хуже только C++ 1 if (a == true) У майкрософта вообще то рекомендуется еще хуже: C++ 1 if (false != a)

представьте, что ошиблись и вместо
Кстати, C# не пропускает

0

Предлагаю всем подумать над следующим тезисом: "Всё, что выглядит, как утка, и крякает, как утка, то и есть утка".

Существует ли такая конструкция на C++, которая принимается компилятором над bool и отвергается над целыми числами (явно указан числовой тип переменной) 1 и 0?

0

DrOffset, mporro, а я предлагаю обсудить следующее:
Чисто гипотетически представим себе что мы волшебным образом убрали из языка haskell (и многих других) логический тип. Теперь посмотрим какие особенности языка мы потеряли. В случае с haskell мы потеряли возможность логического ветвления в программе. Теперь нам недоступны if_then_else и частично pattern matching.
Теперь также представим себе что мы волшебным образом изъяли из языка c++ тип bool. Какие возможности языка мы потеряли?

0

castorsky
Не очень удобно оперировать понятием "потеряли возможность".
Если кто-то вырезал у нас bool, разве мы не в состоянии задать сами тип из двух значений True и False и задать правила для выражения if_then_else?

Разница именно в том, что в Haskell if_then_else определено таким образом, что правила над if_then_else ясны только для True и False. И наш исполнитель должен впасть в ступор, если вместо False подставить 0. У него просто нет правил для такого выражения.

В С++ для встроенной конструкции if () {} else {} можно, как мне кажется, сказать, что она редуцируется по правилу: совпадение с нулём -> else, во всех остальных случаях первый блок. Логического типа просто нет, так как правила для выражение if () {} else {} уже определены через целочисленный аргумент.
По-моему так.

0

Сообщение от mporro Если кто-то вырезал у нас bool, разве мы не в состоянии задать сами тип из двух значений True и False и задать правила для выражения if_then_else?

Верно. В этом случае нам придется костылить/хакать ядро. Следовательно в языке логический тип есть неотъемлемая его составляющая.

Сообщение от mporro Логического типа просто нет, так как правила для выражение if () {} else {} уже определены через целочисленный аргумент..

В этом же случае у нас ничего не изменится. Ну нет больше логического типа и хрен сним. Язык без него продолжает функционировать так же как и с ним. Вопрос: зачем он нужен? Ответа не будет потому что он не нужен, т.к. ломает си совместимость. Но с какой целью этот тип вводится в ядро языка? Кто знает всех тараканов членов комитета, члены комитета по стандартизации common lisp оказались в этом плане куда более прозорливыми и их опыт был на поверхности. А следовать за людьми, которые не умеют учитывать чужой опыт (как негативный, так и позитивный) глупо. Так же глупо как и цитировать нелепости этих людей в качестве истины последней инстанции.

0

Сообщение от castorsky Но с какой целью этот тип вводится в ядро языка?

Ответ на этот вопрос возвращает нас к теме "популярности".
И тип bool, который бы добавлял ключевые слова true и false к Си, был определённым запросом C-программистов.
На самом деле если прочесать исходники на Си, то макро-определения BOOL и FALSE будут встречаться частенько.
Иметь, пусть и целочисленный и синонимичный, тип bool просто удобно с точки зрения чтения исходного кода.
Ввести специальный "логический тип" над конструкцией if () {} else {}, понятно, нельзя -- разрушится C-совместимость.
Вот Страуструп и предложил вариант выхода.

Не понимаю, почему такой подход стоит осуждать столь сильно.

0

Сообщение от mporro На самом деле если прочесать исходники на Си, то макро-определения BOOL и FALSE будут встречаться частенько.

Не разу не встречал.

Сообщение от mporro И тип bool, который бы добавлял ключевые слова true и false к Си, был определённым запросом C-программистов.

Тип bool в С++ появился вместе с визуальными средствами разработки. Единственное его назначение - задание посредством RTTI диапазона ручного ввода значений в Object Inspector.

0

Сообщение от gazlan Укажите, какой из операндов (или выражение в целом) имеет тип bool?

Никакой. Результат выражения будет приведен к bool. И сравниваться будет prvalue типа bool.

Сообщение от gazlan Конверсия (причем, неявная - на платформе, где false есть нуль, компилятор никаких приведений к bool выполнять не будет) возникает именно в момент сравнения результата вычисления выражения с нулем. Что, собственно, и было стартовой точкой.

Мы же понимаем, что наличие или отсутствие приведения не зависит от платформы? Приведение с точки зрения языка будет в любом случае. А вот отразится ли оно в машинном коде, это отдельный разговор. Говоря про язык (исключительно про язык), а не про кодогенератор или оптимизатор (которые, как известно, в современных компиляторах можно заменить довольно просто) выражение будет приводиться к bool всегда, ибо:

(2.2) When used in the condition of an if statement or iteration statement... ....... Certain language constructs require that an expression be converted to a Boolean value.

Сообщение от castorsky Чисто гипотетически представим себе что мы волшебным образом убрали из языка haskell (и многих других) логический тип. Теперь посмотрим какие особенности языка мы потеряли. В случае с haskell мы потеряли возможность логического ветвления в программе. Теперь нам недоступны if_then_else и частично pattern matching. Теперь также представим себе что мы волшебным образом изъяли из языка c++ тип bool. Какие возможности языка мы потеряли?

Риторика в стиле священных войн (если бы бабушка была дедушкой), и на что я надеялся...
Объяснение поведения, к которому апеллирует риторика в последних сообщениях уже дано было давно

Сообщение от 0x10 это следствие не отсутствия типа, а слабой типизации языка.

Сообщение от mporro Существует ли такая конструкция на C++, которая принимается компилятором над bool и отвергается над целыми числами (явно указан числовой тип переменной) 1 и 0?

А почему не подумать над тем, существует ли такая конструкция, которая допустима для char или short, но отвергается над int?
bool - это интегральный тип. И для него применимы все операции, которые применимы для других интегральных типов (хотя использование ++ и -- на данный момент является deprecated).

Добавлено через 3 минуты

Сообщение от castorsky Так же глупо как и цитировать нелепости этих людей в качестве истины последней инстанции.

Мы находимся в профильном разделе С++. Если здесь стандарт С++ не истина в последней инстанции (и, что характерно, компиляторы это подтверждают), то тогда что/кто? Ты или может быть mporro?

2

Сообщение от goditsa8 Вы не погорячились? что такого плохого в if (a==0)

именно вот это сравнение очень плохое. Сравнивать с нулем часто действительно очень не умно.

Сообщение от goditsa8 Вы не погорячились? что такого плохого в if (a==0) if (a==false)

В любое из этих сравнений можно нечаянно прописать присваивание.

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

Неужели нужны еще недостатки?

0

Сообщение от Fulcrum_013 задание посредством RTTI диапазона ручного ввода значений в Object Inspector.

Вы не могли бы поподробнее нам рассказать, зачем конкретно здесь Вам понадобился именно тип bool?
Может быть можно было обойтись отображением целых чисел?

Совершенно не важно кто конкретно начал внедрять явно bool в реализацию C++.
Главное, что bool -- это запрос программистов. И описание bool появилось у Страуструпа до явного принятия стандарта.

Сообщение от DrOffset А почему не подумать над тем, существует ли такая конструкция, которая допустима для char или short, но отвергается над int?

Можно подумать и над этим.
Если бы все конструкции над char принимались бы int, но существовали бы конструкции, отвергаемые для char и принимаемые для int, то мы бы говорили о том, что int расширяет char. Но из-за неявных преобразований таких конструкций нет. Так как int мы может всегда привести к char, то наличие такой конструкции привело бы к противоречию в языке. Получается, что над char и int верны ровно одни и те же конструкции. Потому различить эти объекты по поведению мы не можем совершенно. В этом и проблема слабой типизации. Тип вроде бы и есть, и мы знаем, что представление различается, но по поведению различить не можем, что саму типизацию уже нивелирует.

Другое дело, что переходя на уровень представления, мы, всё же, можем различить char и int. Так что для указателей мы уже имеем разное поведение и разные классы в смысле Рассела, и можем говорить о различных типах.

0

Сообщение от DrOffset Объяснение поведения, к которому апеллирует риторика в последних сообщениях уже дано было давно

Риторика бога и носителя истины в последней инстанции. Слабость типизации тут ни при чем. Банальная си совместимость. Нужно быть слепым фанатиком чтобы сознательно этого не замечать.

Сообщение от DrOffset Если здесь стандарт С++ не истина в последней инстанции (и, что характерно, компиляторы это подтверждают), то тогда что/кто?

А что Вы скажете на то что эта часть стандарта нужна только тем кто пишет компилятор крестов? Ему прост онадо привести свой компилятор в соответствие этому порой абсурдному документу. Что он и делает. Мне же как пользователю тула "наплевать" на тонкости реализации типов.

Сообщение от DrOffset А почему не подумать над тем, существует ли такая конструкция, которая допустима для char или short, но отвергается над int?

al, ax, eax ... продолжать? char, shot, int, long - это всё один тип - целочисленный. float, double, long double - другой тип, bool - третий ненужный тип.

Сообщение от DrOffset Ты или может быть mporro?

Ну пока только ты выделился подобной риторикой.

0

Сообщение от mporro Получается, что над char и int верны ровно одни и те же конструкции. Потому различить эти объекты по поведению мы не можем совершенно. В этом и проблема слабой типизации. Тип вроде бы и есть, и мы знаем, что представление различается, но по поведению различить не можем, что саму типизацию уже нивелирует. Другое дело, что переходя на уровень представления, мы, всё же, можем различить char и int. Так что для указателей мы уже имеем разное поведение и разные классы в смысле Рассела, и можем говорить о различных типах.

Ну да. Именно об этом и речь. Все дело изначально в слабой типизации, а не в наличии bool как типа в С++.
Только вот товарищ castorsky почему-то уверен

Сообщение от castorsky При наличии булева типа в языке со строгой типизацией компилятор это не пропустит.

, что в С++ она сильная и на этом строит всю свою дальнейшую аргументацию.

Добавлено через 9 минут

Сообщение от castorsky Риторика бога и носителя истины в последней инстанции.

Все ясно. Можно было бы с этого начать и больше не продолжать. Никто бы слова против не сказал

Сообщение от castorsky Банальная си совместимость. Нужно быть слепым фанатиком чтобы сознательно этого не замечать.

Язык С еще более слабо типизированный. Одна приводимость void* к любому указателю неявно чего стоит. Поэтому в этом смысле С-совместимость (с которой я, кстати, не спорил) не отменяет слабой типизации С++.

Сообщение от castorsky А что Вы скажете на то что эта часть стандарта нужна только тем кто пишет компилятор крестов?

Скажу, что это не так. Выше были примеры. Вполне можно написать программу, которая использует факт приводимости к bool в построении своей логики. Таких примеров уйма. Тот же ostream это использует для проверки состояния потока.

Сообщение от castorsky al, ax, eax ... продолжать?

Покажешь мне такие на сигнальном процессоре?

0