Вопрос к знатокам С. Опции

[demiurg_spb]

Возник тут вопрос.
Кусочек программы можно написать двумя способами,
но с одним и тем же правильным результатом (компилятор avr-gcc 4.1.2).
Вопрос: это можно взять на вооружение?
И что стандарт может нам сказать по этому поводу?
Спасибо.

Код

//============================================
    unsigned char temp;

    temp = *uart->pUDR;   // Очищаем буфер 3-его уровня.
    temp = *uart->pUDR;  
    temp = *uart->pUDR;  

//============================================
    *uart->pUDR;   // Очищаем буфер 3-его уровня.
    *uart->pUDR;  
    *uart->pUDR;

[ARV]

гм... я и не говорил, что пустой if - это норма... я как раз придерживаюсь противоположного мнения... а вот присваивание временной переменной с моей точки зрения - вполне нормальная практика, логичная и не нарушающая никакие стандартны-нормы-правила. volatile тут совсем ни при чем - этот модификатор никто не отменял и его значение (и назначение) не оспаривается.

на счет "специально заведенных переменных"... на сколько я понимаю, при определенном напряжении сил можно очень сложные выражения (например, нечто типа БПФ) уместить в единственном операторе, избежав "лишних" переменных (обычно они называются локальными)... и, хотя с точки зрения результата это будет совершенно верное "выражение", назвать его удобочитаемым будет можно вряд ли. скорее всего и по объему результирующего кода результат не будет отличаться от "развернутого" варианта...

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

можно сколько угодно рассуждать о том, что компилятор "должен сделать", если встретит просто упоминание переменной, но ведь если записать чуть иначе - пропадет сам предмет спора, ибо поведение компилятора станет очевидно на 100%.

[defunct]

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

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

Во-первых избегать появления дурного кода - т.е. сводить в минимуму потребность в таких вот "var;" и лишних переменных. С какого бодуна драйвер решил вдруг опустошить содержимое буферов? Ведь можно построить драйвер так, что тупое опустошение не понадобится вовсе! Или почему SPSR надо обязательно читать в никуда?
Можно же хотя бы в целях статистики хранить последнее значение SPSR:

Код

ISR()
{
   ...
   spiContext.LastSpsrVal = SPSR;
}

производительности-то оно не сожрет.

во-вторых - применять практику самодокументируемого кода - завести однозначно понятные макросы:

Код

#define access( x )  // обращение к X
#define ignore( x )  // игнорировать x
...

Встретив в коде

Код

access( SPSR );

Даже те "кто в танке" сразу поймут, что делается с SPSR.
А столкнувшись с "финтом" компилятора - достаточно поменять только тело макроса...

[zltigo]

С какого бодуна драйвер решил вдруг опустошить содержимое буферов? Ведь можно построить драйвер так, что тупое опустошение не понадобится вовсе!

Научите у LPC2000 за тем-же SPI есть FIFO которое
- не отключается
- нет возможности сбросить его
Как сделать запись по SPI так, что-бы когда-нибудь при чтении можно было прочтать SPI, а не содержимое забитого при записи FIFO.

Или почему SPSR надо обязательно читать в никуда?
Можно же хотя бы в целях статистики хранить последнее значение SPSR:

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

Код

VICVectAddr = i;            // Dummy write to signal end of interrupt

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

spiContext.LastSpsrVal = SPSR;
производительности-то оно не сожрет.

Да? Вместо, например, команды чтения в первый попавшийся расходный регистр будет производится считывание (для load/store через тот-же промежуточный регистр) в структуру находяшуюся в памяти.....

Даже те "кто в танке" сразу поймут, что делается с SPSR.

Угу, приходишь в магазин, а там на бутылке с маслом надпись
масло(масло);
Начинаешь думать, а чего это вдруг так написали - может смысл какой есть? Смотришь header спрашиваешь и тебе объясняют,что это масло для танкистов.... . В общем-то конечно можно макрос написать, но лишняя сущность.

[defunct]

Научите у LPC2000 за тем-же SPI есть FIFO которое
- не отключается
- нет возможности сбросить его
Как сделать запись по SPI так, что-бы когда-нибудь при чтении можно было прочтать SPI, а не содержимое забитого при записи FIFO.

Думаю, счетчик отправленных байт должен помочь. Драйвер будет вытаскивать из FIFO ровно то количество байт, которое он запихнул при записи.

Я бы не отказался и от обратной возможности - записи "ничего", а то бывает приходится писать, например,

Код

VICVectAddr = i;            // Dummy write to signal end of interrupt

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

Можно дать константу (опять же если производительности хватает).
VICVectAddr = 0;
или
VICVectAddr = CurrentVector;
будет чуть-чуть дольше, зато интуитивно понятно, что делается.

Да? Вместо, например, команды чтения в первый попавшийся расходный регистр будет производится считывание (для load/store через тот-же промежуточный регистр) в структуру находяшуюся в памяти.....

Да, тут сознательно добавляем запись в память. Медленнее чем в регистр - да, сильно скажется на производительности всей системы - нет! (всего лишь запись одной ячейки на FIFO циклов SPI). Польза от этой записи - когда свалимся в DABT, можно будет снять дамп и посмотреть состояние железа, в т.ч. и значение SPSR (вдруг именно его значение поможет найти причину аборта).

Я говорю не отказаться, а свести к минимуму потребность в пустых чтениях, пустых переменных, и прочем дурном коде, и чтобы не быть пустословным показываю как можно этого добиться. А выбор делать так или нет - как всегда за разработчиком.

Угу, приходишь в магазин, а там на бутылке с маслом надпись
масло(масло);

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

В общем-то конечно можно макрос написать, но лишняя сущность.

Дело привычки. Например как Вы поступите если есть некий шаблон колбека:

Код

typedef void (*putmsg_cb)(char *, int, int)

и куча функций подпадающих под этот шаблон, но не использующих все параметры?

Мне удобно поступать так:

Код

void xx_putmsg( char *msg, int size, int priority)
{
    ignore( priority ); // <-- избавились от warning'a и сразу видно, что параметр priority нафиг не нужен
    ...
}

[zltigo]

Думаю, счетчик отправленных байт должен помочь. Драйвер будет вытаскивать из FIFO ровно то количество байт, которое он запихнул при записи.

Вопрос ведь в том, КУДА ОН ИХ БУДЕТ ДЕВАТЬ после ВЫТАСКИВАНИЯ? Выбрасывать? Вы обещали научить меня писать драйвера

.... так, что тупое опустошение не понадобится вовсе!

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

будет чуть-чуть дольше, зато интуитивно понятно, что делается.

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

Дело привычки. Например как Вы поступите если есть некий шаблон колбека:

Код

typedef void (*putmsg_cb)(char *, int, int)

и куча функций подпадающих под этот шаблон, но не использующих все параметры?

Мне удобно поступать так:

Код

void xx_putmsg( char *msg, int size, int priority)
{
    ignore( priority ); // <-- избавились от warning'a и сразу видно, что параметр priority нафиг не

Будете смеяться, но мне - удобно АБСОЛЮТНО аналогично .

Код

#define argsused(foo) (void)(foo)
argsused( priority );

Только это совсем разные случаи, ибо в описываемый ранее
SPSR;
Абсолютно самодостаточен и не совершенно не нуждается, в отличии от priority, ни в каких мусорных обертках ignore( SPSR ); Если хотите сделать понятным для "танкистов", то напишите комментарий - "танкист" чуть-чуть выглянет из люка и узнает немного нового

[defunct]

Вопрос ведь в том, КУДА ОН ИХ БУДЕТ ДЕВАТЬ после ВЫТАСКИВАНИЯ? Выбрасывать?

Складывать в кольцевой буфер, и "семафорить - данные есть". Если эти данные хоть кому-то нужны, обрабатывающий процесс их заберет, если не нужны драйвер перетрет их нафиг по кольцу. Но взятки - гладки, свою работу - принять, нативно опустошить, просигналить - драйвер сделал.

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

Это перебор. Я такого не обещал, к тому же Вы и так умеете их писать.
А порассуждать как можно написать драйвер, чтобы избежать пустых чтений - это пожалуйста.

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

Под "умным" опустошением понимаем - монотонную работу драйвера. Не ему решать что полезно, а что бесполезно. Принимать без разбора драйвер должен абсолютно все, что физически приходит, и отдавать upper layer'у на рассмотрение.

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

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

if (a || b && c)
или
if (a || (b && c) )
вроде одно и то же, но второе ведь наглядней.

Будете смеяться, но мне - удобно АБСОЛЮТНО аналогично .

Смеяться не буду, - хорошо, что мы на одной волне в этом вопросе

Только это совсем разные случаи, ибо в описываемый ранее
SPSR;
Абсолютно самодостаточен и не совершенно не нуждается, в отличии от priority

Я бы не был так категоричен. Потому что SPSR - это не переменная, а макрос. Что там за ним спрятано - хз. Скажете, а UM на что, а если его нет под рукой у читателя кода?

ни в каких мусорных обертках ignore( SPSR ); Если хотите сделать понятным для "танкистов", то напишите комментарий - "танкист" чуть-чуть выглянет из люка и узнает немного нового

шутку понял

Но все же
argused()
ignore()
accessed()
и т.п. делают код прозрачнее, и гибче при переносе.

[Сергей Борщ]

if (a || b && c)
или
if (a || (b && c) )
вроде одно и то же, но второе ведь наглядней.

Это далеко не одно и то же. Логические операции И и ИЛИ всегда выполняются слева направо. Даже компилятор не имеет права изменить этот порядок. Эквивалентным будет if (( a || b ) && c) и со скобками действительно нагляднее.

[defunct]

Это далеко не одно и то же. Логические операции И и ИЛИ всегда выполняются слева направо. Даже компилятор не имеет права изменить этот порядок. Эквивалентным будет if (( a || b ) && c) и со скобками действительно нагляднее.

А приоритеты операций?

Все-таки
if (a || b && c)
или
if (a || (b && c) )
это одно и то же.
Если есть время, просимулируйте вот этот тестик:

Код

void test(void)
{
   int a = 1;
   int b = 0;
   int c = 0;

   if (a || b && c )
      printf("1 || (0 && 0)");
   else
      printf("(1 || 0) && 0");
}

У меня результат этого теста - "1 || (0 && 0)". (RVDS 2.2 и 3.1).

[Сергей Борщ]

А приоритеты операций?

Все-таки
if (a || b && c)
или
if (a || (b && c) )
это одно и то же.

Точно. Приоритеты подзабыл. Решил, что у них одинаковый приоритет. Посыпаю голову окурками.

[defunct]

Да все в порядке. Как раз хороший пример получился - лишний раз подчеркнуть логику работы кода - это только плюс.