При преобразовании множества в многочлен теряется независимость. И простота логических операций. (Авто-)Расширение множества решается не созданием многочлена, а только наличием дополнительного бита у каждого операнда. Либо созданием правил расширения. Преобразование множества в многочлен этот дополнительный бит не порождает. А правила создания этого бита будут и в модели с множеством и в модели с многочленом. Во многих случаях принципиально иметь/работать с множеством, а не многочленом.

Сообщение отредактировал GetSmart - May 24 2016, 09:20

Оказывается в С++11 структура "булевая алгебра" уже реализована посредством шаблона класса bitset.
С одной стороны получается даже излишнее: набор алгебр практически любой размерности, с другой стороны все "bitwise операции" в смысле буля реализованы только между членами класса.

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

~((bitset<16>)temp1) - инвертирование в смысле буля
~temp1 - ивертирование в смысле алгебры многочленов.

Остается дело за малым: bitset-ы размерности равных основным типам добавить к основным, при этом введя побитовые операции между типами bitset и основными, соответственно добавив функции а-ля "to_ulong" для этих размерностей - чтобы узаконить преобразования по умолчанию.
При этом, соответственно поделиться синонимами, так как это непозволительная роскошь попусту транжирить ключевые слова:
~, &, |, ^ - отдать основным битсетам, а comp, bitand, bitor, xor - оставить как есть - нынешним битвайзам.
Гуру языка, скорее всего, за такое изменение синтаксиса будет мучительно невыносимо, но зато начинающему большинству, еще не отягощенному знаниями стандарта такая реформа будет естественной.

Сообщение отредактировал aiwa - May 23 2016, 21:21

Перечитываю себя и нахожу не совсем то, что хотел донести. От греха подальше поправлюсь.

(Авто-)Расширение множества решается, например, наличием дополнительного бита у каждого операнда.



Огласите, пожалуйста, весь список где в С++ отличается результат тильды и побитовой инверсии. Если нет разницы, то зачем платить больше?
Применительно к целочисленным и enum операндам. Естественно, без переопределений тильды.

Сообщение отредактировал GetSmart - May 25 2016, 10:01

Список не предоставлю по причинам:
Во-первых я нигде не утверждал, что результат тильды в С++ отличается от побитовой инверсии.
Я только цитировал стандарт, что тильда определена как дополнение, что однозначно указывает принадлежность этой операции к набору операций двоичной арифметики многочленов.
Во вторых, также я не утверждал что компилятор компилирует не так как предписывает стандарт: компилятор строго ему следует.


Применительно к целочисленным и enum операндам, разница состоит в том, что приходится платить больше - набором дополнительных служебных слов и ухудшением из-за этого читабельности.
в обсуждаемом случае это для избавления от незванного подарка стандартом С++ в виде дополнительных поднятых 16-ти битах: (uint_16)(~var16)
Как другой, но более ресурсоемкий вариант: очистить результат маской, либо расширить вручную единичными разрядами.

В 98% случаев необходимость в побитовых операциях возникает не как к целочисленным (или enum) типам а именно как к набору бит.
98% я, конечно, написал от фонаря, 1% оставив разработчикам стандарта, другой 1% - прочитавшим стандарт для проверки, если вдруг захочется.
Косвенным доказательствам этого является введение в стандарт "по просьбам трудящихся" типа набора бит: bitset.

Появился третий вариант альтернативных действий, но тоже дополнительных: ~((bitset<16>)var16).

Но в 98% случаях нужно платить больше: набирать лишнее преобразование, захламляя текст, во втором - добавляя еще и команду, а в третьем вызывая еще и конструктор копирования.

При этом в оставшихся %2 случаях, текст кода остается "по умолчанию".

98% и 2% логично поменять местами.

Помогите пожалуйста восполнить пробел в познаниях языка.
почему компилятор может выбрасывать условие if(a==0)?



ассемблер


Контроллер STM32F103, IAR ARM 6.10 (проверил и на 7.80), оптимизация по максимуму. toggle_led - внешняя функция, меняет состояние порта. Выбрасывается именно условие if(a==0), если поставить toggle_led без условия, то функция выполняется.

Видимо оптимизатор компилятора не учитывает возможность переполнения, и для него переменная a принимает значения от 5 до 500.

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

если Вам таки нужна переменная a вочтобытонистало



Внимательно перечитайте все warn - запустите анализатор кода C-STAT StaticAnalysis (в меню Project).
Если оно есть в Вашем IAR/Target

Сообщение отредактировал k155la3 - Apr 26 2017, 05:56

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

Вот оставить два вызова toggle_led() и пустой цикл мог бы запросто.

Удалить if компилятор может как из-за условия, так и из-за тела. Условие обозначено вполне корректное. Даже volatile не требуется переменным. А вот содержимое toggle_led() не обозначено. Поэтому утвержтать, что ИАР неправ - преждевременно.

если заменить присваивание a=5 на a=12 (или больше 12), то все работает как надо.


Никаких предупреждений нет.

с глобальной переменной работает правильно (без __root - тоже).



сам проект

Так не факт, что это преднамеренно. Но судя по этому:

у IARа таки есть проблема.

toggle_led ()

Еще. Код ниже исправно выводит в порт значения переменной. А условие не выполняется, какой бы код в него не был бы помещен. Его просто нет в листинге.

в терминале:

Вроде уже объяснили - обычный глюк оптимизатора. Пишите понятные программы и они будут работать безглючно.

Как вариант замените a++ на a = (a+1) & 0xFF, ну и расскажите нам заработало ли...

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

А ещё, неожиданно, может оказаться uint8_t шириной более 8 бит и ИАР окажется прав. Но по логу терминала видно, что он 8-битный.
И, если при изменении нач.значения a на 12 код создаётся правильный, то оправдать ИАР не получается. Может оптимизатор на этапе компиляции (почему-то) изменяет ширину переменной до 9 бит, при 12+500 получается как раз 0 в 9-битовой переменной.

PS
Архив не смотрел.

Сообщение отредактировал GetSmart - Apr 27 2017, 12:04

нет, ни один из вариантов не помогает, пока переменная 8-ми битная.
условие a == 0x100 - то же не выполняется (на случай, если компилятор считает ее более 8 бит).
Помогает только использовать переменную 16-бит

ну раз глюк, то и ладно. Вопрос можно закрыть. Я уж думал, что вообще ничего не понимаю.

Сообщение отредактировал vit496 - Apr 27 2017, 08:14