@goditsa8

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

0

@ct0r

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

0

@S_el

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

0

@Fulcrum_013

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

0

@DrOffset

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

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

Вот теория:
4/2
4/4
4.12/1
Вот практика:
http://rextester.com/TISS75398
http://rextester.com/MPKNZQ7125

Добавлено через 7 минут
С++ требует. Смотри цитаты выше.
Конкретная реализация не играет в этом смысле роли.

0

@castorsky

м.б. в каких-то Ваших личных теориях. Я их не знаю.
Очень смешно, кэп. Я уже говорил об этом.

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

0

@gazlan

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

0

@DrOffset

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

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

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

1

@gazlan

OK.

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

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

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

0

zer0mail

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

0

@mporro

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

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

0

@castorsky

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

0

@mporro

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

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

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

0

@castorsky

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

0

@mporro

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

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

0

@Fulcrum_013

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

0

@DrOffset

Никакой. Результат выражения будет приведен к bool. И сравниваться будет prvalue типа bool.
Мы же понимаем, что наличие или отсутствие приведения не зависит от платформы? Приведение с точки зрения языка будет в любом случае. А вот отразится ли оно в машинном коде, это отдельный разговор. Говоря про язык (исключительно про язык), а не про кодогенератор или оптимизатор (которые, как известно, в современных компиляторах можно заменить довольно просто) выражение будет приводиться к bool всегда, ибо:
Риторика в стиле священных войн (если бы бабушка была дедушкой), и на что я надеялся...
Объяснение поведения, к которому апеллирует риторика в последних сообщениях уже дано было давно
А почему не подумать над тем, существует ли такая конструкция, которая допустима для char или short, но отвергается над int?
bool - это интегральный тип. И для него применимы все операции, которые применимы для других интегральных типов (хотя использование ++ и -- на данный момент является deprecated).

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

2

@daslex

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

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

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

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

0

@mporro

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

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


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

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

0

@castorsky

Риторика бога и носителя истины в последней инстанции. Слабость типизации тут ни при чем. Банальная си совместимость. Нужно быть слепым фанатиком чтобы сознательно этого не замечать.
А что Вы скажете на то что эта часть стандарта нужна только тем кто пишет компилятор крестов? Ему прост онадо привести свой компилятор в соответствие этому порой абсурдному документу. Что он и делает. Мне же как пользователю тула "наплевать" на тонкости реализации типов.
al, ax, eax ... продолжать? char, shot, int, long - это всё один тип - целочисленный. float, double, long double - другой тип, bool - третий ненужный тип.
Ну пока только ты выделился подобной риторикой.

0

@DrOffset

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

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

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

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

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

0