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

@goditsa8 · Регистрация: 04.02.2013

Author24 — интернет-сервис помощи студентам

Сообщение от Fulcrum_013

людей которые пишут

C++

if (a==0)

а тем более

C++

1	if (a==false)

вместо

C++

if (!a)

Умными или адекватными назвать трудно.

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

C++

if (a==0)

или

C++

1	if (a==false)

?

@castorsky · 29.06.2015, 15:24

Сообщение от DrOffset

Поэтому в этом смысле С-совместимость (с которой я, кстати, не спорил) не отменяет слабой типизации С++.

Только Вы путаете причину и следствие. Выдавая следствие за причину и наоборот. Цель - си совместимость, слабость типизации (тоже почему-то именно в этом вопросе, а не в остальных случаях) - следствие. Следовательно bool - костыль. Ненужно.

Сообщение от DrOffset

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

А слона-то Вы решили ненароком не заметить. А вот он:

Сообщение от castorsky

char, shot, int, long - это всё один тип - целочисленный

Сообщение от DrOffset

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

Факты применения не относятся к теме разговора. Осветите функциональныю составляющую этого типа в языке. Те возможности, которые он добавляет в язык и те возможности, которые без этого типа нивелируются.

@DrOffset · 29.06.2015, 15:42

Сообщение от castorsky

Только Вы путаете причину и следствие. Выдавая следствие за причину и наоборот. Цель - си совместимость, слабость типизации (тоже почему-то именно в этом вопросе, а не в остальных случаях) - следствие.

Пусть так. Только как это влияет на присутствие или отсутствие типа? Ну сделан bool таким для совместимости. Ну унаследовал С++ слабую типизацию от С. Да, сначала унаследовал, потом слабую. Я с этим не спорю и не "не замечаю". Что это меняет-то? В стандарте тип есть, компиляторы его требуют, используется он сейчас уже повсюду.

Сообщение от castorsky

char, shot, int, long - это всё один тип - целочисленный

bool тоже в этом списке.

Сообщение от castorsky

Следовательно bool - костыль. Ненужно.

Тип есть, но он не нужен. Твое право так думать. Хорошо.

Сообщение от castorsky

Те возможности, которые он добавляет в язык и те возможности, которые без этого типа нивелируются.

Твоя попытка притянуть за уши свойства типа bool из Haskell не выдерживают критики. Вообще говоря, можно обойтись одним единственным целочисленным типом, например int. Без short и long прекрасно можно обойтись. И никаких принципиальных возможностей, которые нивелируются их отсутствием, они тоже не добавляют. Только странно делать на основе этого выводы, что будто бы остальные типы не нужны. Так чем bool так провинился?

@castorsky · 29.06.2015, 16:40

Моё imho по этому вопросу

Сообщение от castorsky

Это кстати хорошая фишка для любого языка, иметь абсолютный нуль и не иметь самостоятельного булева типа.

Но в крестах есть и абсолютный нуль, и булев тип, ВП. Под абсолютным нулем тут понимается то что всегда ложь, а все остальное - истина. Независимо от типов, как в си, cl, forth.

Сообщение от DrOffset

bool тоже в этом списке.

Это печально xD

Сообщение от DrOffset

Вообще говоря, можно обойтись одним единственным целочисленным типом, например int. Без short и long прекрасно можно обойтись. И никаких принципиальных возможностей, которые нивелируются их отсутствием, они тоже не добавляют.

Тут Вы недооцениваете положение. Можно и на BrainF* писать. На множестве целочисленных типов определены функции (или операции, кому как удобней). Можно исходить из того что булев тип - подмножество целого, но тогда и множество функций обязано распространяться на этот тип, что противоречит мат аппарату.

Сообщение от DrOffset

Так чем bool так провинился?

Да ни чем. Просто лишняя сущность.

Мне вообще все равно, просто товарищи начали доказывать какую-то ерунду.

@DrOffset · 29.06.2015, 16:59

castorsky, ладно. Мне твое мнение понятно. Если будем продолжать, то тему придется переносить в другой раздел, а мне бы этого не хотелось.
Будь здоров.

@Voivoid · 29.06.2015, 17:58

Сообщение от Fulcrum_013

И читать трудно и набирать долго и язык не учили, не знают что 0==false

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

@goditsa8 · 29.06.2015, 18:39 **[ТС]**

Не по теме:

Ничего себе, топик создал случайно. )))

Нет, все правильно, сравнивать в условии переменную с истиной или ложью смысла большого нет, сам так не делаю (делаю, если не высплюсь))). Но криминала в этом тоже нет. Не называть же человека "не умным" или "не адекватным", из-за того, что он пишет x = x + y вместо x += y. По крайней мере подобные ошибки поправимы, а вот если человек на 2-м курсе не понимает, что такое указатель, то это уже плохо.

@Fulcrum_013 · 30.06.2015, 04:51

Сообщение от Voivoid

А разгадка-то проста, байтослесарям лишь относительно недавно завезли тип bool

Ну я ж и говорю - что не дай монкейкодерам из мелкософта из всего придется C# делать.

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

Сообщение от goditsa8

а вот если человек на 2-м курсе не понимает, что такое указатель, то это уже плохо.

А для тех кто не понимает что такое указатель после получения диплома и кучи сертификатов разработчика микрософт придумали C#.
Вопрос в том что если человек не понимает как if работает то до понимания что такое указатель... НУ во многом это связано что кодеры микрософта не компилят то что они набирают. Конвейер. аналитики аналитят, блок-схемки малюют, кодеры их кодят, более продвинутые компилят... мало понятно как потом весь этот г-код дебагят... но в конечном итоге как то работает.

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

Сообщение от goditsa8

из-за того, что он пишет x = x + y вместо x += y

В некоторых случаях только так и работает. к примеру Если есть __property T3DVector Pos у которого есть геттер и сеттер, то Obj.Pos.x+=delta уйдет в никуда, сработает только Obj.Pos.x=Obj.Pos.x+delta;

Добавлено через 4 часа 55 минут

Сообщение от DrOffset

Одна приводимость void* к любому указателю неявно чего стоит

Так он для этого и нужен, чтобы лишние явные приведения не городить. А поскольку явно указатель приводится к чему угодно, то без неявного приведения void * - бессмыслица.

@DrOffset · 30.06.2015, 15:47

Сообщение от Fulcrum_013

А поскольку явно указатель приводится к чему угодно, то без неявного приведения void * - бессмыслица.

В С++ он неявно не приводится, только в С.

@Fulcrum_013 · 30.06.2015, 23:43

Сообщение от DrOffset

В С++ он неявно не приводится, только в С.

Хорошо хоть к void * неявно приводится, а то в нем бы вообще смысла не было.

Убежденный · 01.07.2015, 08:49

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

Ничего.

Tulosba · 01.07.2015, 14:05

Сообщение от DrOffset

хотя использование ++ и -- на данный момент является deprecated

Декремент не разрешен вообще для bool.

Сообщение от mporro

Получается, что над char и int верны ровно одни и те же конструкции.

Про перегрузку по типу не в курсе?

C++

#include <iostream>
 
void f(char)
{
    std::cout << "char\n";
}
 
void f(int)
{
    std::cout << "int\n";
}
 
int main() {
 
    f('a'); // char
    f(42); // int
 
    return 0;
}

C++

1
2

if (a==0) // если a - целое, то вполне нормальное условие.
if (a==false) // если a - целое, то это странное условие, если bool, то лаконичнее будет '!a'

@mporro · 01.07.2015, 14:45

Сообщение от Tulosba

Про перегрузку по типу не в курсе?

C++

void f(int)
{
    std::cout << "int\n";
}
 
int main() {
 
    f('a'); // int
    f(25); // int
 
    return 0;
}

Какие ещё могут быть вопросы?

Добавлено через 28 минут
Tulosba, перегрузка между char и int говорит о том, что для компилятора это существенно разные слова. И это правильно! Потому что в представлении эти сущности различаются. Указатели char* и int* инвариантны. А вот char и int из друг друга вытекают.
Именно это и есть недостаток нестрогой типизации. Слова-то есть, а типов-то нет.

Tulosba · 01.07.2015, 15:34

Сообщение от mporro

Какие ещё могут быть вопросы?

Ты сказал, что

Сообщение от mporro

Получается, что над char и int верны ровно одни и те же конструкции.

Я показал, что ты не прав, в общем случае, т.к. язык позволяет различать эти типы.

Сообщение от mporro

Указатели char* и int* инвариантны.

Сделай функцию, принимающую void*, и любой указатель для нее будет подходящим.

@Voivoid · 01.07.2015, 15:42

Сообщение от mporro

Слова-то есть, а типов-то нет.

Вот это уровень экспертизы! У меня просто нет слов

@mporro · 01.07.2015, 15:59

Tulosba,

Сообщение от Tulosba

язык позволяет различать эти типы.

Нет, различные метки и различные типы -- не одно и тоже.
Тип -- это не просто синтаксическая метка, а такая метка, которая позволяет при синтаксической редукции выражений доказать отсутствие определённого поведения.

Если мы возьмём и переименуем все целые числа в числа-Tulosba, то мы новый тип не определим, мы определим синоним. Нет возможности создать такую конструкцию из чисел-Tulosba, чтобы она оказалась недопустимым поведением для целых чисел, равно как и обратное.

Char -- некоторая синтаксическая метка, с этим никто не спорит. И она нужна С++, потому что за ней скрывается некоторая реализация. Реализация определена в стандарте. Но абстракция объекта char инкапсулирует реализацию. И мы уже char с int как объекты не различаем. Нельзя написать такое выражение, которое было бы осмысленным только для char или было бы осмысленным над другим целочисленным типом, но неопределённым над char.

Сообщение от Tulosba

Сделай функцию, принимающую void*

Да. Всё, что осмысленно над void* может быть редуцировано и над другим указателем. Потому все указатели наследуют void*. Но мы легко можем написать выражение, которое имеет ясный смысл для char* и бессмысленно над void*: сложение с единицей, разименование. Потому void* не наследует char*. Таким образом, char* и void* не просто синтаксические метки, но конструкции ограничивающие поведение. Их уже можно называть типами если и не в смысле Пирса, то в смысле Рассела.

@castorsky · 01.07.2015, 15:59

Сообщение от Tulosba

Про перегрузку по типу не в курсе?

Ваш пример никак не опровергает цитируемое высказывание. Он лишь демонстрирует наличие полиморфных функций, а множество функций над целочисленными типами остается для всех одинаковым, равно как и управляющие конструкции языка будут одинаково валидны для целочисленных типов. О чем товарищ и выразился.

@Voivoid · 01.07.2015, 16:17

Лол, так что в итоге-то? А то я что-то не до конца уловил, что, собственно, хотят сказать многоуважаемые господа. Что bool это синоним типа int? Или что?

На всякий случай напомню, что времени, когда приходилось писать typedef int bool прошли

Tulosba · 01.07.2015, 16:27

castorsky, не вижу смысла спорить с человеком, у которого максимальное кол-во сообщений в ветке "Священные войны"

С 99,9999% вероятностью текущая тема скатится туда же. Тенденция уже очень хорошо прослеживается.
Если кого-то смущают неявные преобразования встроенных типов C++, то у меня два вас как минимум 2 предложения:
- не использовать C++;
- создать пользовательские типы;
И если кто-то выбирает первый вариант, то и обсуждение ведите, пожалуйста, уже в другом разделе форума.

@castorsky · 01.07.2015, 19:10

Теперь Ваше нелепое высказываение уже не выглядит нелепым на фоне моей активности в СВ. Всё ясно. Можно продолжить "логические" умозаключения и задаться вопросом: а стоит ли вообще обращать внимание на тех смердов, чья карма меньше? С вероятностью в 99.9999% именно я окажусь как провокатор флуда.

@castorsky 1978 / 1082 / 87 Регистрация: 29.11.2013 Сообщений: 3,353
	29.06.2015, 15:24	61
	Сообщение от DrOffset Поэтому в этом смысле С-совместимость (с которой я, кстати, не спорил) не отменяет слабой типизации С++. Только Вы путаете причину и следствие. Выдавая следствие за причину и наоборот. Цель - си совместимость, слабость типизации (тоже почему-то именно в этом вопросе, а не в остальных случаях) - следствие. Следовательно bool - костыль. Ненужно. Сообщение от DrOffset Покажешь мне такие на сигнальном процессоре? А слона-то Вы решили ненароком не заметить. А вот он: Сообщение от castorsky char, shot, int, long - это всё один тип - целочисленный Сообщение от DrOffset Вполне можно написать программу, которая использует факт приводимости к bool в построении своей логики. Таких примеров уйма. Тот же ostream это использует для проверки состояния потока. Факты применения не относятся к теме разговора. Осветите функциональныю составляющую этого типа в языке. Те возможности, которые он добавляет в язык и те возможности, которые без этого типа нивелируются. 0

@DrOffset 18844 / 9843 / 2408 Регистрация: 30.01.2014 Сообщений: 17,285
	29.06.2015, 15:42	62
	Сообщение от castorsky Только Вы путаете причину и следствие. Выдавая следствие за причину и наоборот. Цель - си совместимость, слабость типизации (тоже почему-то именно в этом вопросе, а не в остальных случаях) - следствие. Пусть так. Только как это влияет на присутствие или отсутствие типа? Ну сделан bool таким для совместимости. Ну унаследовал С++ слабую типизацию от С. Да, сначала унаследовал, потом слабую. Я с этим не спорю и не "не замечаю". Что это меняет-то? В стандарте тип есть, компиляторы его требуют, используется он сейчас уже повсюду. Сообщение от castorsky char, shot, int, long - это всё один тип - целочисленный bool тоже в этом списке. Сообщение от castorsky Следовательно bool - костыль. Ненужно. Тип есть, но он не нужен. Твое право так думать. Хорошо. Сообщение от castorsky Те возможности, которые он добавляет в язык и те возможности, которые без этого типа нивелируются. Твоя попытка притянуть за уши свойства типа bool из Haskell не выдерживают критики. Вообще говоря, можно обойтись одним единственным целочисленным типом, например int. Без short и long прекрасно можно обойтись. И никаких принципиальных возможностей, которые нивелируются их отсутствием, они тоже не добавляют. Только странно делать на основе этого выводы, что будто бы остальные типы не нужны. Так чем bool так провинился? 1

@castorsky 1978 / 1082 / 87 Регистрация: 29.11.2013 Сообщений: 3,353
	29.06.2015, 16:40	63
	Моё imho по этому вопросу Сообщение от castorsky Это кстати хорошая фишка для любого языка, иметь абсолютный нуль и не иметь самостоятельного булева типа. Но в крестах есть и абсолютный нуль, и булев тип, ВП. Под абсолютным нулем тут понимается то что всегда ложь, а все остальное - истина. Независимо от типов, как в си, cl, forth. Сообщение от DrOffset bool тоже в этом списке. Это печально xD Сообщение от DrOffset Вообще говоря, можно обойтись одним единственным целочисленным типом, например int. Без short и long прекрасно можно обойтись. И никаких принципиальных возможностей, которые нивелируются их отсутствием, они тоже не добавляют. Тут Вы недооцениваете положение. Можно и на BrainF* писать. На множестве целочисленных типов определены функции (или операции, кому как удобней). Можно исходить из того что булев тип - подмножество целого, но тогда и множество функций обязано распространяться на этот тип, что противоречит мат аппарату. Сообщение от DrOffset Так чем bool так провинился? Да ни чем. Просто лишняя сущность. Мне вообще все равно, просто товарищи начали доказывать какую-то ерунду. 0

@DrOffset 18844 / 9843 / 2408 Регистрация: 30.01.2014 Сообщений: 17,285
	29.06.2015, 16:59	64
	castorsky, ладно. Мне твое мнение понятно. Если будем продолжать, то тему придется переносить в другой раздел, а мне бы этого не хотелось. Будь здоров. 0

@Voivoid 710 / 283 / 16 Регистрация: 31.03.2013 Сообщений: 1,340
	29.06.2015, 17:58	65
	Сообщение от Fulcrum_013 И читать трудно и набирать долго и язык не учили, не знают что 0==false Просто лол. А разгадка-то проста, байтослесарям лишь относительно недавно завезли тип bool, поэтому они и раскорячивались как могли. А потом уже настолько к этому привыкли, что считают теперь, что это норма. Каргокультисты, что с них взять. Как тут не вспомнить историю про обезьян которых поливали водой при попытке сорвать банан 0

@goditsa8 15 / 15 / 3 Регистрация: 04.02.2013 Сообщений: 124
	29.06.2015, 18:39 [ТС]	66
	Не по теме: Ничего себе, топик создал случайно. ))) Нет, все правильно, сравнивать в условии переменную с истиной или ложью смысла большого нет, сам так не делаю (делаю, если не высплюсь))). Но криминала в этом тоже нет. Не называть же человека "не умным" или "не адекватным", из-за того, что он пишет x = x + y вместо x += y. По крайней мере подобные ошибки поправимы, а вот если человек на 2-м курсе не понимает, что такое указатель, то это уже плохо. 0

@Fulcrum_013 2063 / 1542 / 168 Регистрация: 14.12.2014 Сообщений: 13,402
	30.06.2015, 04:51	67
	Сообщение от Voivoid А разгадка-то проста, байтослесарям лишь относительно недавно завезли тип bool Ну я ж и говорю - что не дай монкейкодерам из мелкософта из всего придется C# делать. Добавлено через 4 минуты Сообщение от goditsa8 а вот если человек на 2-м курсе не понимает, что такое указатель, то это уже плохо. А для тех кто не понимает что такое указатель после получения диплома и кучи сертификатов разработчика микрософт придумали C#. Вопрос в том что если человек не понимает как if работает то до понимания что такое указатель... НУ во многом это связано что кодеры микрософта не компилят то что они набирают. Конвейер. аналитики аналитят, блок-схемки малюют, кодеры их кодят, более продвинутые компилят... мало понятно как потом весь этот г-код дебагят... но в конечном итоге как то работает. Добавлено через 10 минут Сообщение от goditsa8 из-за того, что он пишет x = x + y вместо x += y В некоторых случаях только так и работает. к примеру Если есть __property T3DVector Pos у которого есть геттер и сеттер, то Obj.Pos.x+=delta уйдет в никуда, сработает только Obj.Pos.x=Obj.Pos.x+delta; Добавлено через 4 часа 55 минут Сообщение от DrOffset Одна приводимость void* к любому указателю неявно чего стоит Так он для этого и нужен, чтобы лишние явные приведения не городить. А поскольку явно указатель приводится к чему угодно, то без неявного приведения void * - бессмыслица. 0

@DrOffset 18844 / 9843 / 2408 Регистрация: 30.01.2014 Сообщений: 17,285
	30.06.2015, 15:47	68
	Сообщение от Fulcrum_013 А поскольку явно указатель приводится к чему угодно, то без неявного приведения void * - бессмыслица. В С++ он неявно не приводится, только в С. 0

@Fulcrum_013 2063 / 1542 / 168 Регистрация: 14.12.2014 Сообщений: 13,402
	30.06.2015, 23:43	69
	Сообщение от DrOffset В С++ он неявно не приводится, только в С. Хорошо хоть к void * неявно приводится, а то в нем бы вообще смысла не было. 0

Убежденный Ушел с форума 16473 / 7436 / 1187 Регистрация: 02.05.2013 Сообщений: 11,617 Записей в блоге: 1
	01.07.2015, 08:49	70
	Что плохого в явном написании условия в if? Ничего. 0

Tulosba :) 4773 / 3267 / 497 Регистрация: 19.02.2013 Сообщений: 9,046
	01.07.2015, 15:34	73
	Сообщение от mporro Какие ещё могут быть вопросы? Ты сказал, что Сообщение от mporro Получается, что над char и int верны ровно одни и те же конструкции. Я показал, что ты не прав, в общем случае, т.к. язык позволяет различать эти типы. Сообщение от mporro Указатели char* и int* инвариантны. Сделай функцию, принимающую void*, и любой указатель для нее будет подходящим. 0

@Voivoid 710 / 283 / 16 Регистрация: 31.03.2013 Сообщений: 1,340
	01.07.2015, 15:42	74
	Сообщение от mporro Слова-то есть, а типов-то нет. Вот это уровень экспертизы! У меня просто нет слов 0

@mporro 306 / 101 / 18 Регистрация: 04.07.2014 Сообщений: 571
	01.07.2015, 15:59	75
	Tulosba, Сообщение от Tulosba язык позволяет различать эти типы. Нет, различные метки и различные типы -- не одно и тоже. Тип -- это не просто синтаксическая метка, а такая метка, которая позволяет при синтаксической редукции выражений доказать отсутствие определённого поведения. Если мы возьмём и переименуем все целые числа в числа-Tulosba, то мы новый тип не определим, мы определим синоним. Нет возможности создать такую конструкцию из чисел-Tulosba, чтобы она оказалась недопустимым поведением для целых чисел, равно как и обратное. Char -- некоторая синтаксическая метка, с этим никто не спорит. И она нужна С++, потому что за ней скрывается некоторая реализация. Реализация определена в стандарте. Но абстракция объекта char инкапсулирует реализацию. И мы уже char с int как объекты не различаем. Нельзя написать такое выражение, которое было бы осмысленным только для char или было бы осмысленным над другим целочисленным типом, но неопределённым над char. Сообщение от Tulosba Сделай функцию, принимающую void* Да. Всё, что осмысленно над void* может быть редуцировано и над другим указателем. Потому все указатели наследуют void. Но мы легко можем написать выражение, которое имеет ясный смысл для char и бессмысленно над void: сложение с единицей, разименование. Потому void не наследует char. Таким образом, char и void* не просто синтаксические метки, но конструкции ограничивающие поведение. Их уже можно называть типами если и не в смысле Пирса, то в смысле Рассела. 0

@castorsky 1978 / 1082 / 87 Регистрация: 29.11.2013 Сообщений: 3,353
	01.07.2015, 15:59	76
	Сообщение от Tulosba Про перегрузку по типу не в курсе? Ваш пример никак не опровергает цитируемое высказывание. Он лишь демонстрирует наличие полиморфных функций, а множество функций над целочисленными типами остается для всех одинаковым, равно как и управляющие конструкции языка будут одинаково валидны для целочисленных типов. О чем товарищ и выразился. 0

@Voivoid 710 / 283 / 16 Регистрация: 31.03.2013 Сообщений: 1,340
	01.07.2015, 16:17	77
	Лол, так что в итоге-то? А то я что-то не до конца уловил, что, собственно, хотят сказать многоуважаемые господа. Что bool это синоним типа int? Или что? На всякий случай напомню, что времени, когда приходилось писать typedef int bool прошли 0

Tulosba :) 4773 / 3267 / 497 Регистрация: 19.02.2013 Сообщений: 9,046
	01.07.2015, 16:27	78
	castorsky, не вижу смысла спорить с человеком, у которого максимальное кол-во сообщений в ветке "Священные войны" С 99,9999% вероятностью текущая тема скатится туда же. Тенденция уже очень хорошо прослеживается. Если кого-то смущают неявные преобразования встроенных типов C++, то у меня два вас как минимум 2 предложения: - не использовать C++; - создать пользовательские типы; И если кто-то выбирает первый вариант, то и обсуждение ведите, пожалуйста, уже в другом разделе форума. 0

@castorsky 1978 / 1082 / 87 Регистрация: 29.11.2013 Сообщений: 3,353
	01.07.2015, 19:10	79
	Теперь Ваше нелепое высказываение уже не выглядит нелепым на фоне моей активности в СВ. Всё ясно. Можно продолжить "логические" умозаключения и задаться вопросом: а стоит ли вообще обращать внимание на тех смердов, чья карма меньше? С вероятностью в 99.9999% именно я окажусь как провокатор флуда. 0