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

[jcxz]

iD-audio писал(а):

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

Самый лучший способ: Всё время смотреть в листинг! Написали строчку кода, скомпилили (с макс.оптимизацией), посмотрели в листинг - что получилось? И следующая итерация. И т.д.

iD-audio писал(а):

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

Так и следует делать.

iD-audio писал(а):

Но самостоятельно это довольно долгий путь.

Быстро только кошки плодятся.
Если будете делать это несамостоятельно, то в голове ничего не останется.

[OKF]

jcxz писал(а):

Самый лучший способ: Всё время смотреть в листинг! Написали строчку кода, скомпилили (с макс.оптимизацией), посмотрели в листинг - что получилось? И следующая итерация. И т.д.

Нафига? Это смотря какие цели.) К примеру, я хочу писать красиво и лаконично. На кой мне листинг?)

[Jack_A]

OKF писал(а):

К примеру, я хочу писать красиво и лаконично. На кой мне листинг?)

Между "я хочу" и "я умею" есть некоторая разница. Когда это десятки раз писалось в разных вариантах и успешно работало - можно и без листинга. Да и то: в сложных случаях непонятно - то ли компилятор дурит, то ли сам накосячил. А вид сгенерированного кода всё расставит по местам.

[OKF]

Ой. "Компилятор дурит" - это уже говорит о многом. Не обижайтесь.)

[Martian]

Вера в безгрешность компилятора тоже о многом может сказать. Например, что верующий не использовал XC8/16/32, список ошибок которых достаточно большой. Не знаю, как сейчас, а раньше в фреймворке Микрочипа было явно указано не включать оптимизацию XC8.
Компилятор - это как бэ всё-таки тоже программа. Со всеми её свойствами.

[OKF]

Обычно, начинающие все свои ошибки списывали на компилятор.)

[Jack_A]

OKF писал(а):

Не обижайтесь.)

Чего мне обижаться - я же не компилятор А начинающим (по программному делу) я был этак в году 76-м прошлого тысячелетия.
А насчёт наличия ошибок в компиляторе... Когда в преферансе мне сетовали за недозаказ - я спрашиваю:
- А если 4 на 4 в двух мастях на одной руке?
- Ну, этого никогда не бывает.
- Значит, ты мало играл. У меня случалось.

То-то и оно.

© А.Пугачёва, жена иноагента.

[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);


[Martian]

uint8_t eeprom_read_byte...

[OKF]

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

[Martian]

перед сдвигом влево требуется приведение к типу uint16_t

[OKF]

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

[Martian]

Результат имеет uint16_t. Но сдвиг об этом ничего не знает, его приоритет выше.
и опять же: число скобок бесконечно во вселенной. a << b | c(d) можно прочитать и как a << (b | c(d)). И да, я верю, что все знают приоритеты, но пишу так: (a << b) | c(d)

[OKF]

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

[Martian]

у нас не религия. Правила есть, да. Почему же Вы им не следуете?

[OKF]

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