ещё раз прочитайте ответ - вы обязаны записать это выражение правильно, иначе получайте предупреждение
кто должен разбираться, что там у вас там такое эти 1, 2..., или вы сможете вспомнить через полгода, что оно означало ?

Таки да, операция ~temp1 дает число 0xFFFFFFFE. Вот если результат инверсии сохранить в uint16_t, тогда урежется до 0xFFFE.
Я тут внес сумятицу в дискуссию...
Отладчик Кейловский (чемпион!) рулит.

Вот именно. Для правильной генерации кода, наверное, предлагается напомнить компилятору о правильной размерности таким кодом:
if( (int16u)(~temp1) != temp2)

Который явно не способствует читабельности.

Абыдно, что у С++ масло маслянное.

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

Где-то вы не договариваете. Тот код, что вы привели с локальными переменными, с позиции современных компиляторов является "мертвым" кодом и может быть выкинут безо всяких предупреждений даже на низших уровнях оптимизации.

Перепишем ваш пример в более корректную форму:

и посмотрим на труд комиплятора (gcc -O2):

Все просто превосходно - не правда ли? Цикл заменен единственной инструкцией, а все потому, что сам код при любых значениях входных переменных будет всегда возвращать значение переменной temp2. Компилятор увидел это, и выкинул абсолютно ненужный цикл.

Что-же касается молчаливого выбрасывания "мертвого" кода, то это есть следствие многопроходности современных компиляторов и весьма сложных структур внутреннего представления. Кроме того, конструкции вида


широко используются при условной компиляции без использования препроцессора.

Поверьте, ничего я не "не договариваю". В топике я разместил код в таком виде, в каком проблема (на мой взгляд))
воспроизводилась, и с которой я столкнулся. Я считал что этого достаточно, так как легко можно проверить.
Затем, в сообщении 53 я привел законченные примеры кода и результат компиляции IAR.
Вопрос, как и тема раздела в целом, касается исключительно IAR. Причём на уровне оптимизации - None.
Причём я по прежнему считаю, что логика формирования предупреждений у IAR страдает.
1. Переменные 16 битные - код выбрасывается без предупреждений. Вроде мы обосновали, что это логично.
2. Переменные 32 битные - код присутствует, хотя он в этом случае он не менее бессмысленный.
Хотя здесь может быть такой аргумент: Две 32 битные переменные имеют право сравниваться, а компилятор заранее
не обязан предсказывать результат.
3. В случае "if (true) continue;" предупреждение есть, хотя результат ещё более определен, чем в первом случае.
Для меня лично (по результатам обсуждения) логично бы выглядело наличие предупреждения и в первом пункте.
Но видимо это уже связано с многопроходностью компилятора (код выбрасывается на уровне, когда предупреждения
уже не формируются).
Наверное нельзя это оценивать однозначно как хорошо или как плохо. Просто надо иметь в виду, что такая ситуация
возможна и больше обращать внимание на такие неявные на первый взгляд особенности языка и действий компилятора.

Что именно неправильно в моей записи и почему?

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

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

Если "программист" не знает языка и НЕ ХОЧЕТ читать сообщения компилятора ПОДАВИВ ИХ, то да.

Вы вопрос качества языка постоянно сводите к вопросу качества программиста.

Язык такой, какой он есть. Де факто стандарт для программирования микроконтроллеров. Мы все крепки задним умом. Было бы неплохо, конечно, обобщить передовой опыт, родить супер-пупер язык для МК, который в 100500 раз более лучше, чем Си, и отправить его на машине времени туда, куда надо. Но что-то мне подсказывает, что троечникам это не поможет. Учебник всё равно надо читать.

Есть язык, он описан. Как любой ЖИВОЙ язык он имеет опоеделенные правила и умолчания. Их надо знать. Если кто не знает языка и более того, плюет на сообщения, которые генерят компиляторы написанные знающими язык людьми, то это есть проблема "качества порограммиста" и только его.




Спасибо, не надо. Уже рожали. Когда пытабтся рожать язык ради языка, а не дела, то получабтся ублюдки типа Ada, Python и иже с ними.

И что вас здесь смущает? Левый операнд оператора сравнения будет расширен до размера int, а затем инвертирован, что на 32-х битной архитектуре приведет к установке битов старшего слова в 1. Правый операнд в силу беззнакового типа будет дополнен нулями. Очевидно, что 0xffffxxxx != 0x0000xxxx. Если сделать первый операнд знаковым, то результат может показаться странным, т.к. числа до 0х8000 будут давать другой результат. В любом случае, это полностью документированное в стандарте поведение - никаких неожиданностей здесь нет.

Если в законе что-то не написано прямым текстом, то работает принцип аналогии.

Ещё со времён динозавров, компиляторы паскаля, си и многих других языков выдавали сообщение/варнинг при сравнении беззнаковой переменной со знаковой константой или или переменной с константой вне диапазона этой переменной. В примере топикстартера есть аналогичные признаки: сравнение двух выражений, которые заведомо вне диапазона друг друга. Программер имеет право ожидать, что ОБНАРУЖИВ подобную ситуацию, компилятор укажет на неё аналогично константе.

Если компилятор не слишком оптимизирующий, то он действительно может не выдавать сообщение, т.к. во время компиляции эту ситуацию не видит. Компилятор, опознавший always-result в выражении с переменными всё-таки должен (ака вектор эволюции) выдавать сообщение, по аналогии с другими предупреждениями. И профсоюз по защите прав программистов должен лоббировать эти правила )))

Молчание ИАРа тянет на недоработку. Если в публичных и непубличных нормативах не было явно указано на данную ситуацию.

Они и сейчас так делают.

Никакого МОЛЧАНИЯ у IAR, как и других нет, если не не подавлять сообщения. IAR в отношении сообщалок о возможном непонимании, пожалуй даже говорливее всех других:

temp2 = ~A;
[Pa091]: operator operates on value promoted to int (with possibly unexpected result)


if( ~temp1 != temp2)
[Pa091]: operator operates on value promoted to int (with possibly unexpected result)
[Pe068]: integer conversion resulted in a change of sign

Так что может хватит здесь пургу нести?

Питон-то чем не угодил?

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