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

[FreshMan]

1 << (i++ % 2) -- для стробирования ламп надо подать 1 на PC4 или PC5, в заисимости от того что выводить -- десятки или единицы.

нужно подать 0, для того чтобы зажглась лампа единиц или десятков

[ut1wpr]

Кажется я понял в чем затык.

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

while(1)
...
PORTC = (m[i] & 0x0F) | 1 << (i++ % 2 + 4);
...

Это вывод каждого разряда за 1 проход. Что он делает:
m[i] -- берет значение разряда десятки\единицы
(m[i] & 0x0F) -- убираем лишние данные, не относящиеся к выводимому значению (можно опустить)
1 << (i++ % 2) -- для стробирования ламп надо подать 1 на PC4 или PC5, в заисимости от того что выводить -- десятки или единицы. Инструкция i++ % 2 убирает нужду добавлять оператор if
m[i] | 1 << (i++ % 2) -- битовая сумма операторов, что в конечном итоге даст нужно число на порте

Вообще-то, компилятор с включенной оптимизацией все наши потуги накрутить лишнего приведет к единственно короткому виду. Лишь бы логика наших мудреностей не противоречила его "здравому смыслу"
Я к тому, что иногда применение вами нелюбимых if может существенно облегчить как понимание, так и написание программы. Не забывайте, что в конечном итоге результатом компиляции будет программа в машинных кодах, где будут присутствовать куча условных и безусловных переходов в сочетании с вводами/выводами в порты и шевелениями отдельных битов.
Тем и могуч язык Си, что можно кучей разных способов описать одно и то же.
Это лишний раз подтверждает необходимость знания системы команд целевого МК, для которого пишете. Хотя бы в минимальных объемах.
Таковы правила эмбеддинга, никуда от этого не деться.

[juzik]

нужно подать 0, для того чтобы зажглась лампа единиц или десятков

Я особо не разбирался в схеме. Инвертируйте, если не так.

[juzik]

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

Простите, а к чему этот пост? Про оптимизацию никто и не спрашивал, человеку было не понятно как связать концы с концами и я лишь попытался помочь. Возможно, не самым удачным способом. Да и один и то же алгоритм я могу написать разными способами, что заставит компилятор интерпретировать его по-разному.
Причем тут оператор if? Это один из вариантов реализации данной задачи. Кстати говоря, более оптимизированный, чем блоки условий, в данном контексте. Компилятор это программа, она не умеет "думать" и "предсказывать" в полном смысле этого слова. Так что полностью доверять ему бессмысленно.

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

И каким образом Ваше высказывание о необходимости знания целевого мк относится к моему посту? В своих знаниях, так сказать, я уверен.

juzik, учитесь править цитаты. Не научитесь — будет бан за оверпостинг и многоэтажное цитирование.

Gudd-Head

[ut1wpr]

Простите, а к чему этот пост?..

Недостаток текстовых чатов - отсутствие возможности передавать акценты написанного. Это я про себя. В глубине лично ваших знаний нет ни малейшего сомнения.
Мой пост вообще-то адресовался не вам, но с использованием ваших цитат. За что и извините. Мои рекомендации насчет целевого процессора лишь намек, что в машинных кодах оттранслированная программа под разные МК с разными системами команд будет выглядеть по разному. Опять таки это не вам, а тому, кто этого не знает.
Насчет if ведь наше мнение совпало? Я так понял... Покажите место, где я "добавил от себя" о их ненужности? Возможно, выразился неудачно, но основная идея моей подсказки состояла в том, чтобы человек не увлекался относительно сложными конструкциями языка и постоянно помнил, что однострочные, труднопонимаемые построения в любом случае скомпилируются в одинаковый результат, как если бы текст был написан просто, "по рядочкам", отдельными командами. Экономия на строках Си в программе ВУ не означает экономии в кодах. Вот что я хотел объяснить человеку.
Причем не исключаю, что он это уже знает. Но по себе сужу, в свое время, пораженный мощью и универсальностью языка я выписывал тааакие конструкции... Почему-то старался чуть-ли не всю функцию описать одной строчкой.
Впрочем, это уже на OFF сворачивает, посему с извинениями откланиваюсь.

ut1wpr, вы тоже учитесь править цитаты.

Gudd-Head

[juzik]

Виноват, не уловил первоначальной идеи. Сори если обидел.

[ut1wpr]

ut1wpr, вы тоже учитесь править цитаты.
Gudd-Head

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

[FreshMan]

мне нужно переменную n каждый раз уменьшать на 16
правильна ли сия команда ?
n--16;

[AI_Disable]

мне нужно переменную n каждый раз уменьшать на 16
правильна ли сия команда ?
n--16;

нет. n-=16;

[ut1wpr]

мне нужно переменную n каждый раз уменьшать на 16
правильна ли сия команда ?
n--16;

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

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

n = n - 16;

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

[FreshMan]

в примерах часто вижу вот такую запись
PORTD &=~((1<<1)(1<<0));

а можна ли записать так:
PORTD &=0b11111100

[uldemir]

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

[FreshMan]

ой......., извиняюсь.........., там так написано:

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

PORTD &=~((1<<1)|(1<<0));

[vitalik_1984]

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

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

#define  SET 0
#define  LED 1
PORTD &=~((1<<LED)|(1<<SET));
 

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

А вы пробовали это компилировать?
Как насчет ошибки неожиданная скобка?

[ut1wpr]

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

Скорее всего вносить коррективы можно будет в любом случае. Просто с применением дефайнов их можно вынести из тела программы и поместить в отдельном месте.
Это облегчит поиск этих определений в случае необходимости внесения изменений. Найти же отдельную строку в программе, да к тому же совершенно не прокомментированную, будет трудно даже автору программы.
Особенно после 8-го марта. На утро 9-го..

А вы пробовали это компилировать?
Как насчет ошибки неожиданная скобка?

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

[FreshMan]

меня как новичка будоражит такой вопрос: как ПРАВИЛЬНО выстроить СТРУКТУРУ программы при ее написании ?

[IfoR]

Этот вопрос аналогичен вопросу: "Как правильно обустроить мою комнату дома?" У каждого программиста найдется свои стиль программирования, который ему наиболее удобен. Тут можно только что рассказать некоторые частоупотребимые шаблоны, такие как тут выше рассказывали.

Но тем не менее, если собираешься выставлять свой код на всеобщее обозрение, то для таких случаев есть, так сказать, негласные правила программирования (про них где-то можно почитать в сети), такие как стиль названия переменных (ex: void * pointerToSomething; или void * pointer_to_something;), а названия дефайнов делают заглавными буквами (ex: #define NUMBER_OF_NUMBERS 10), перед макросами к этому ещё и ставят нижнее подчёркивание (ex: #define _BV(x) (1<<(x))). Это всё нужно, чтобы любой человек, увидев какое либо подобное слово, мог по его названию что оно собой представляет. Ну и весь код добротно сдабривается комментариями.

[ut1wpr]

меня как новичка будоражит такой вопрос: как ПРАВИЛЬНО выстроить СТРУКТУРУ программы при ее написании ?

Структура программы будет определяться самим программистов в зависимости от алгоритмики решений. А вот стиль написания у каждого свой. Есть попытки выработать некие общие рекомендации, но в любом случае каждый имеет право ваять, как ему вздумается. И он этим правом лихо пользуется, затрудняя чтение и понимание своих программ сторонним программистам.
Те не менее, можно порекомендовать почитать вот это: http://www.pic24.ru/doku.php/osa/articles/encoding_without_errors. Без претензий на истину в первой инстанции.

[IfoR]

Хорошая статья, только, по моему, разделы "Определение функций", "Пустые операторы", "Про оператор switch" (может "Приведение типов") притянуты за уши. По крайней мере, если ты знаешь, что делаешь. Ну а раз ты сам пишешь программу, то ты знаешь что делаешь.
Да и округлять дробные значения можно просто добавив 0.5 к округляемому, а не придумывать какие-то формулы, которые, кстати, если их упростить, дадут тот же самый результат (f = X + 0.5).

[Мастер Ломастер]

перед макросами к этому ещё и ставят нижнее подчёркивание (ex: #define _BV(x) (1<<(x))).

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

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