Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
Задание было - сделать программу, которая сравнивает две схемы, вводиме пользователем? Тогда да, этот фрагмент вообще не в тему и ничего не даст. Или надо было написать сравнения именно этих двух схем? Тогда не говнокод. Потому что адекватность кода соответствует адекватности задания. То, что функции совпадают, и так очевидно.
И во что при это превратились бы выражения для f1 и f2? По-моему, 15 вложенных циклов значительно яснее, чем огромное выражение с кучей логических операций и ещё большей кучей битовых масок.
можно преобразовать счетчик в массив из bool - короткая запись обращения к элементу и короткое преобразование.
Или вытащить вычисление выражений в отдельные функции, и передать им значения отдельных битов как аргументы. Тогда запись подлиннее будет, но зато без лишних сущностей и промежуточных шагов.
если немного подумать можно найти простое решение
(к примеру создать массив или написать функцию для получения бита по индексу)
а вот если у вас будет 128-разр число? 128 вложеных циклов?
вы китаец?
Нет, я сторонник адекватных решений. Для простой тупой одноразовой задачи (а судя по контексту это именно такая задача), по-моему, предложенное решение вполне адекватно. Как часть большое системы - нет. А тут, по-моему, оно соответствует разумном соотношению результат/затраченные усилия.
с каких это пор тупой копи-пейст стал адекватным?
а если цикл на 15 итераций, то вы 15 раз пишете его содержимое?
если есть возможность решить задачу в 5 строк, а она решается в 20 - это
>>разумноe соотношениt результат/затраченные усилия.
Блин, задача решается в ноль строк, вот в чём проблема. И если написали такую хуйню, значит либо автор полный дебил, что не в состоянии в уме перевернуть знак, либо такое задание.
Интересно, каким это методом? Я думаю у Вас приведение этих двух функций к каким-нибудь нормальным формам займёт дольше, чем написание такой программы. Или Вы знаете другие чудодейственные приёмы решения задачи сравнения двух булевых функций?
Для одноразовых задач, которые не являются частью большей системы, адекватным является любое работающее и быстрое (в смысле затраченных усилий) решение. На такое решение у меня уйдёт минут 10 максимум включая отлов случайных багов. Я предполагаю, что над решением в 5 строчек Вы только думать будете дольше, а ещё потом ещё сколько-то времени дебажить разные ошибки в "умном" решении.
как раз нет
мне бы просто было влом копипастить
и менять индексы у х-ов
Кстати копи-паста - это корень многих ошибок ибо провтыкать чего то легко а потом полчаса искать это.
>>быстрое (в смысле затраченных усилий) решение
ну я уже не знаю как объяснить, что приведенное выше решение таковым никак не является ибо что-то вроде
for( int x=0 x1<2^15; x1++ ){
f1 = ( getB(x,1) && getB(x,2) итд..
f1 = ( getB(x,1) || getB(x,2) итд..
if ( f1 != f2 ) Valid = false; break;
}
//не спорю - говнофункция, но это чисто для примеpa
bool getb(int i,int b){
return ((i & 2^(b-1))>0);
}
гораздо быстрее написать
читайте написанное выше
>>можно преобразовать счетчик в массив из bool - короткая запись обращения к элементу и короткое преобразование.
>>к примеру создать массив или написать функцию для получения бита по индексу
Кэп поясняет что будет выглядеть так x[1], x[2] итд
или getBit(1) getBit(2) итд
"Единицы измерения" (типы) соблюдены. 😉
Но в целом, вероятно, надо было:
for( bool x1=false; x1<=true; x1++ )
Хотя конечно инкремент булевых переменных и не рекомендуется стандартом. А вот декремент для bool вообще запрещен.
Это понятно из поста выше. Зачем повторяться?
Говорю, почему это запретили в стандарте? Какие были-бы последствия, если бы не запретили?
Что если я попытаюсь декрементировать булевскую переменную? Получу ошибку компиляции? Что-то типа семантик еррор?
Предыстории почему запретили, я не знаю. Но видимо неспроста, раз уж в стандарте прописано. При компиляции будет ошибка. Если кто знает почему запрещено, было бы интересно узнать. А пока что любой инкремент bool дает true, а декремент запрещен.
Может, чтобы 0 не декрементировали, тогда получится хрен знает что. Когда инкрементируешь, истина становится все толще (разве что кто-то в поисках истины тип обернет:)))), но все равно истина, а тут можешь ложь получить или НЕХ.
Да вообще, любой порядок надо на булях запретить. Чтобы неповадно было.
Чтобы как у Виннипуха: «если он есть, то его сразу нет». Два значения и баста. А то мое true, которое 2, труевее твоего, которое 1. В два раза труевее.
PS. Правда всегда одна, это сказал фараон. Так-то!
Когда такую сигнатуру видишь - содержимое обычно не удивляет
PS. Буквально давеча думал, кому может понадобиться библиотека boolstuff:)
вместо 15 переменных можно было завести ОДНУ 16-битную и использовать ОДИН цикл.
Или вытащить вычисление выражений в отдельные функции, и передать им значения отдельных битов как аргументы. Тогда запись подлиннее будет, но зато без лишних сущностей и промежуточных шагов.
(к примеру создать массив или написать функцию для получения бита по индексу)
а вот если у вас будет 128-разр число? 128 вложеных циклов?
вы китаец?
а если цикл на 15 итераций, то вы 15 раз пишете его содержимое?
если есть возможность решить задачу в 5 строк, а она решается в 20 - это
>>разумноe соотношениt результат/затраченные усилия.
ану-ка покажите решение в 0 строк :^)
кэп ваш код нерабочий
Фейлите, товарищъ.
Вы ursus?
У меня нормально, все правильно сделал!
Если ты не можешь решить эту задачу в уме, то иди гуляй.
мне бы просто было влом копипастить
и менять индексы у х-ов
Кстати копи-паста - это корень многих ошибок ибо провтыкать чего то легко а потом полчаса искать это.
>>быстрое (в смысле затраченных усилий) решение
ну я уже не знаю как объяснить, что приведенное выше решение таковым никак не является ибо что-то вроде
for( int x=0 x1<2^15; x1++ ){
f1 = ( getB(x,1) && getB(x,2) итд..
f1 = ( getB(x,1) || getB(x,2) итд..
if ( f1 != f2 ) Valid = false; break;
}
//не спорю - говнофункция, но это чисто для примеpa
bool getb(int i,int b){
return ((i & 2^(b-1))>0);
}
гораздо быстрее написать
b1 = step & 0001h
b2 = step & 0002h
b3 = step & 0004h
итд.
Один хуй.
>>можно преобразовать счетчик в массив из bool - короткая запись обращения к элементу и короткое преобразование.
>>к примеру создать массив или написать функцию для получения бита по индексу
Кэп поясняет что будет выглядеть так x[1], x[2] итд
или getBit(1) getBit(2) итд
>>b1 = step & 0001h
>>b2 = step & 0002h
это говноподход
За что?
"for ( bool var = false", надо будет запомнить, просто гениально!
Но в целом, вероятно, надо было:
for( bool x1=false; x1<=true; x1++ )
Хотя конечно инкремент булевых переменных и не рекомендуется стандартом. А вот декремент для bool вообще запрещен.
Говорю, почему это запретили в стандарте? Какие были-бы последствия, если бы не запретили?
Что если я попытаюсь декрементировать булевскую переменную? Получу ошибку компиляции? Что-то типа семантик еррор?
Надрочили "стандартов" на полторы тыщи листов и сами не знаете что для чего и зачем оно...
Чтобы как у Виннипуха: «если он есть, то его сразу нет». Два значения и баста. А то мое true, которое 2, труевее твоего, которое 1. В два раза труевее.
PS. Правда всегда одна, это сказал фараон. Так-то!
И не нужно жутких арифметических действий.
Зато мы теперь знаем, как получить чередующуюся последовательность false-true-false-...
Человек, придумавщий это, достоин уважения.
и де моргана пусть докажет
вдруг все что я знал -- не правда?!
И если можно то чуть по-больше чем 15, а то надо точно проверить
зы: я только сейчас задумался: а coq же это питух
Ты с дельфи/паскалем не перепутал?
и это не вижалси, это билдер борладновый судя по вот этим вот T