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

Если это был намек в мой адрес - то я не латыш, я русский. Но мы оба латвийцы, да. Точно также как не каждый россиянин является русским. С белорусами в этом плане сложнее

Чем дальше в лес, тем толще партизаны

Можно поспорить, что красивее. Но не стоит. Ваше решение я помню. Применял именно там, где хидерописатели напутали с описанием битов латентности флэш.

Тогда - латвийцы.
В Беларуси тоже много национальностей. Я сам - космополит наполовину.

Тут как значения битов, а не только _0 с расчетом на умножение. Совершенно обыденно.

PWR_CR_PLS_0*7 для получения (PWR_CR_PLS_0|PWR_CR_PLS_1|PWR_CR_PLS_2) Что-то мне это нифига красивым не кажется.
PWR_CR_PLS(7) - приемлимо. А лучше в таком выражении эту семерку задефинировать:
#define PLS_OC4REF (7)
И получим:
PWR_CR_PLS(PLS_OC4REF)

, что читабельнее и БЕЗОШИБОЧНЕЕ комментариев при изменениях. Причем расписывать все комбинации сразу нет никакой необходимости. Нужные режимы добавляются в процессе работы. Получается никак не более трудоемко, чем комментарии.


Такое нужно в дополнительную обертку заворачивать. Иначе ЧЕЛОВЕЧЕСКИЙ глаз таки режет

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

de gustibus non est disputandum

Я в том смысле, что такая запись позвляет отличать битовое поле от одиночных битов:

Вот еще добавлю...
Вдруг после очередного обновления пресловутого КУБа обнаружилось, что после старта АЦП с ДМА второй АЦП уже не стартует нормально.
Подробнее. При пошаговом прохождении в отладчике все как бы нормально, что еще противнее. Лень было разбираться.
Если запустить первый АЦП с внешним запуском, а потом второй АЦП, то так можно обойти проблему.
Где еще зарыли ОНИ подводные камни?
А в старом - я его предусмотрительно оставила, - все нормально идет.
Конечно, основной плюс КУБа в скорости создания инициализации. Особенно для особенно ленивых.

Сейчас пришла в голову мысль: можно завернуть это в constexpr-функцию, и пользовать её. Причём (это моё личное предпочтение) лучше сделать не маску, а номер бита, чтоб было не умножение, а сдвиг. То есть, где-то в заголовочнике:

И где угодно:

Так, возможно, число понявших немножко увеличится
С другой стороны, это только C++, причём C++11. Но я, наверное, буду пользовать.

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

К сожалению, железо развивается быстрее, чем мы накапливаем знания. Документация STM отвратительная и подручная Индия есть не у всех... Короче, слишком часто скорость перевешивает качество и это, по-видимому, чем дальше, тем больше будет основным фактором. C'est la vie.

Думаю, даже меньше
Это чисто математический трюк, не зная который в его смысл нужно въезжать.
Я вот так и не придумал, почему дополнение до машинного слова маски поля бит всегда дает единицу внутри этого поля.
Однако это так
Так что такая запись будет "вырублена на лбу" только после её осмысления.
А стороннего бедолагу разработчика, которому нужно будет подправить этот код может ввести в глубокий ступор.


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

ну не знаю... 0x11001000 * 5 = 0x55005000
это уже на лбу должно быть

Речь не об этом, а о:
0x30 & -0x30 = 0x10

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

Сообщение отредактировал Огурцов - Apr 13 2016, 18:17