Вопросы по С/С++ (СИ)

[OKF]

Да. Я тоже находил ошибки в контроллере HDD. Но это ТАКАЯ редкость. Вы понимаете? В основном, ошибки у начинающих. Которым кажется что виноваты все, кроме них самих.)

[Jack_A]

Можно сформулировать корректнее: не "компилятор глючит", а "есть разное понимание некоторых инструкций у компилятора и юзера". Юзер может считать, что "это ведь так по умолчанию", а у компиля другое мнение.
До сих пор помню,хоть прошло порядочно. Работал в старом, ещё Борландовском Си. Ввожу переменную - портится рядом лежащая! Ошибка не очевидная, трудно улавливаемая. Когда поймал, стал разбираться. Оказывается, для ввода float требовался формат %lf, без вариантов, даже если просто float, а не double. , У меня же просто %f . И получив такой формат, оно вместо предупреждения во всю дурь, на все 16 байт хряпнуло введённое значение. Мол, хрен тебя знает, какая точность тебе нужна, на всяк случай запупырю максимальную. Конечно, моей вины тут больше половины, но при анализе синтаксиса мог бы хоть предупреждение выдать.
Мне скажут: юзер может таких конструкций нагородить, что компилятору вариантов анализа мильён понадобится. А я не спорю. Нужно точно следовать описанию используемой версии языка. Но при анализе ошибки листинг ну никак не помешает - пусть не "что это компайл надурил?", а "в чём у нас между-недопонимание?" И особенно для МК - тут пользователей меньше, поколения МК меняются чаще, и степень "вылизанности" софта по определеню меньше, чем у "the language of general use"

[OKF]

Припоминаю последнюю ошибку компилятора:)

Код: Выделить всё

  eeprom_write_byte(0, 0x34);           //litle-endian
  eeprom_write_byte(1, 0x12);

  uint8_t i = 2;                        //всё плохо: 3412
  uint16_t v = eeprom_read_byte(--i)<<8 | eeprom_read_byte(--i);

[OKF]

А членораздельнее?)

[OKF]

Нафига? Результат у нас какой тип имеет?

[OKF]

Ну, то что для успокоения каждый пишет по своему, это дело каждого. Но, есть же правила. И им пофигу какая у вас религия.

[OKF]

Внимательно читаем приведение типов.

[Z_h_e]

uint16_t v = eeprom_read_byte(--i)<<8 | eeprom_read_byte(--i);

Я правильно понимаю, что у Вас результат, который попал в v, это 0x0034?
Ворнинга не было?

[Z_h_e]

Я сейчас вот такой код попробовал.

Код: Выделить всё

  volatile uint8_t a=0xFF;
  volatile uint16_t v=a<<8 | (uint8_t)1;

Результат 0xFF01.
Ворнинга нет. Компилятор IAR. Пробовал выбирать Stantard C, C89 и С++.

[VladislavS]

Если прогуливать уроки физики в школе, то мир наполнится магией и волшебством
Точно так же, если не читать стандарты на язык программирования. Ключевые слова "Integer Promotions".

[Jack_A]

[uquote="Martian",url="/forum/viewtopic.php?p=4575532#p4575532"]a << сb | c(d)[/uquote]
Давненько не писал на Си, а для МК - вообще никогда. Но заинтересовала эта конструкция. Следуя K & R, насколько я их помню, едино что приходит на ум - процедура c с парамеиром d . Но это, конечно, не так?

[VladislavS]

Это точно не процедура, в С тупо нет процедур, а есть функции. А c(d) может быть как вызовом функции, так и макросом или даже приведением типа. Всё зависит от того что есть c.

[OKF]

[uquote="VladislavS",url="/forum/viewtopic.php?p=4575611#p4575611"]Если прогуливать уроки физики в школе, то мир наполнится магией и волшебством
Точно так же, если не читать стандарты на язык программирования. Ключевые слова "Integer Promotions".[/uquote]
Да. Люблю волшебство.) Ну а беда в том что стандарт не определяет последовательность вычисления операндов:
Except where noted, evaluations of operands of individual operators and of subexpressions of individual expressions are unsequenced ... The value computations of the operands of an operator are sequenced before the value computation of the result of the operator. If a side effect on a memory location (4.4) is unsequenced relative to either another side effect on the same memory location or a value computation using the value of any object in the same memory location, and they are not potentially concurrent (4.7) , the behavior is undefined (ISO/IEC 14882:2017 разд. 4.6(17) стр. 14)

[VladislavS]

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

[Z_h_e]

Я крайне редко пользуюсь тернарным оператором. Боюсь ошибиться.
Но ведь он не просто выполняет одно из выражений , но и возвращает его результат.

Добавлено after 2 minutes 22 seconds:

да и он всегда истинен)

кто?

[VladislavS]

Третьим аргументом функции GPIO_WriteBit() будет значение выражения

Код: Выделить всё

(i == 0) ? (i = Bit_SET) : (i = Bit_RESET)

которое при каждом вызове будет менять своё значение с Bit_SET на Bit_RESET и наоборот. Так дрыганье ногой сделали. Пример в Compiler Explorer.

ЗЫ:
У меня в коде вот такая приколюха с тернарником есть

Код: Выделить всё

bool isKeyPressed() { return key_pressed ? key_pressed=false,true : false; }

[Z_h_e]

Так тернарный оператор возвращает фактический результат, а не булевый тип. То есть результатом i=x , будет x.

[VladislavS]

[uquote="Martian",url="/forum/viewtopic.php?p=4588538#p4588538"]результат присваивания i = x; По крайней мере,[/uquote]Оператор присваивания возвращает правое выражение. Это позволяет делать последовательные присваивания a=b=c;

[Gudd-Head]

[uquote="Martian",url="/forum/viewtopic.php?p=4588538#p4588538"]если слегка ошибиться и написать if (i = x), то у меня было когда-то, что это принималось за истину, и даже где-то читал описание, что в данном случае условие всегда истинно.[/uquote]
На Хабре недавно была статья, что почти все компиляторы стали выдавать предупреждение на присваивание в условии.

[AlexS4]

==,!= вообще декоративные при том что - определен для всего что обычно сравнивают с их помощью