- 1
unsigned long long int value=Bin<unsigned long long int>("1111111111111111111111111111111111111111111111111111111111111111");-
C++ / Говнокод #8405
+991
Запостил:
AnimeGovno-_-,
02 Ноября 2011
Follow us!
И как после этого Си и С++ можно использовать как низкоуровневый язык для контроллеров? Одни тормоза и пустая трата памяти на строки бинарных чисел.
говнокод в сабже намекает, что требуемое число влезает в uint64_t
в чем проблема то? написать LL в конце?
даю подсказку - число из говнокода можно определить не менее чем тремя другими способами
О понятиях декларативности, самодокументирующемся коде, ты конечно же слышал?
И выполнять часть работы компилятора, ты видимо считаешь, почетным делом?
и да, если уж говорить о бинарных числах для контроллеров - расскажи, зачем необходимо объявить именно 0b01001110, а не 0x4e. Что за самодокументирующийся хардкод? А потом удивляются, почему у нас такая мощная тихоокеанская группировка спутников
Cи пригоден, но добавить бинарную форму записи числа в язык, используемый для программирования контроллеров, просто необходимо.
Хоть создатели gcc об этом догадались.
>зачем необходимо объявить именно 0b01001110, а не 0x4e
Например, битовые маски, установленные сигналы и тд. Очень часто в контроллерах на один и тот же порт параллельно приходится вешать много различных устройств, например на 8ми битах порта висит 5 устройств, каждому выделены свои биты.
только баклан будет писать 0b01001110 чтобы передать заданному набору устройств сигнал
синтаксический сахар в виде 0b... нужен либо ленивым, либо неграмотным
Да, чувак, клево делать таким образом битовую маску под device2, а потом таким же образом под все остальные девайсы
теоретик?
к.о. какбе намекает, что она может быть непростой только по одной причине - в ней есть независимые области, каждая из которых что то да значит
никакой разницы в самодокументируемости между 0b01001110 и 0x4e нет совсем, они равноправны с этой точки зрения
а вот хардкодить такие вещи в любом проекте, не только для приведённых тобой "низкоуровневых микроконтроллеров" - плохой зайка
если маска сложная, разбей её на логические части, следующие из целей этих частей, и пиши код в виде value1 & block1_mask | value2 & block2_mask
не делай за компилятор его работу, а программист, который будет разбираться че за хуйня это ваше 01001110, тебе спасибо скажет
Ты из XML собрался загружать, если не хардкодить что ли на контрллере?
device2 = 1 << 1 | 1 << 2 | 1 << 3 | 1 << 5 | 1 << 7;
Вот, я это сделал. Получилось говно. Один девайс - одна маска.
что означают эти биты? каждый из них?
это id устройства? это маска? что это?
Остальные биты относятся к другим устройствам.
Я так и понял, что вы низкоуровневым программированием не занимались. :\
Интересная у вас логика.
Приходилось работать в проекте, где была куча подобного кода, и у меня был жуткий баттхёрт по этому поводу. Подобные куски были разбросаны тут и там, часто встречалась копипаста. Понять без поллитры такие вещи мог только автор кода.
В том случае можно было инкапсулировать логику в нескольких макросах, и код стал бы гораздо более понятным и читаемым.
В высокоуровневом программировании это бы и у меня вызвало батхерт. А в программировании контроллеров по другому особо не сделаешь. Ограничения платформы.
>В том случае можно было инкапсулировать логику в нескольких макросах
А кто запрещает? Поддержка бинарного формата чисел не мешает инкапсулировать логику в макросы или функции.
стек протоколов SS7 в OSE-Delta. Не особо высокий уровень.
По мне так C даёт достаточно средств, чтобы даже самый, казалось бы, низкоуровневый код выглядел читабельно и работал при этом достаточно эффективно.
Кстати, на каком то контроллере видел библиотеку с набором макросов, который позволяет задавать числа в бинарной форме, не смотря на ограничение компилятора. Ни это ли костыли? Не это ли глупо? Почему это до сих пор не внесли в стандарт языка?
Отсутствие бинарной формы - не самый большой недостаток языка C.
>Отсутствие бинарной формы - не самый большой недостаток языка C.
Я понимаю. :(
вывод неверный
почему она не сплошная? может есть какая то разумная причина, по которой в маске есть дырки в середине? мне кажется, от нас что то скрывают
может эту разумную причину стоит кодить разумным образом, а не хардкодом?
Это вопрос к схематехниками, а не к программистам. Может напутали чего. Или напутали, но серию устройств уже выпустили и переделывать не станут. Или были зарезервированные биты, потом чтобы не переразводить устройство или не пересобирать устройство - использовали этот зарезервированный бит. По хорошему биты должны стоять вместе, но реальность диктует свои условия. Часто заменить все устройства у заказчика или пересобрать дороже, чем добавить пару строк кода, немного усложнив код, вынеся бит отдельно от всех остальных битов устройства.
меня просто умилили набросы в стиле "поэтому си невозможно использовать для низкоуровневого языка", 40 лет возможно и удобно, а тут бида бида
Где я такое написал? Регулярно использую. И вообще, я вас конечно понял, но предложение похоже на несвязанный бред.
>тогда не вижу принципиальной разницы между #define device2_mask 0x4e и #define device2_mask 0b...,
А разница есть и это большинству очевидно.
> И как после этого Си и С++ можно использовать как низкоуровневый язык для контроллеров?
>поэтому си невозможно использовать для низкоуровневого языка
Язык Си не возможно использовать для низкоуровнего языка. На си написано столько компиляторов низкоуровневых языков, что тебе и не снилось. Не нужно меня обвинять в своем бреде.
но у спортсмена обязательно будет еще одна бонусная попытка
Ты ещё школьный курс русского языка не закончил? Это семантическая ошибка, а не орфографическая.
Вам? От всего.
ввод или\и вывод на устройство производится через них.
Покажи код на примере с дивайсами
Я бы посмотрел, как ты это написал через битовые поля
Порядок бит, говорят, зависит от реализации, но мы же, программируя микроконтроллер, воспользуемся компилятором, генерирующим код для этого микроконтроллера, в котором этот порядок так или иначе определён.
something.mean2 = 1;
Фи. Хочу
const char cm=0b101;
...
something.mean=cm;
, а не по отдельности все биты устройства выставлять или читать. Так придется править код везде, где я общаюсь с mean, если у неё появятся новые биты или они перекочуют.
У меня это ключевое слово в кавычках не случайно. Семантически reinterpret_cast в Си есть, только используется по другому.
Костыль. Во время компиляции вообще проверки на совпадение типов не будет. Это как минимум, дает лишние места для возможных ошибок.
На производительности и объёмах занимаемой памяти - использование структур, битовых полей и приведений типов сказывается отрицательно. Иногда для контроллеров это не допустимо.
...
> а не по отдельности все биты
А это было не по отдельности?
> если у неё появятся новые биты или они перекочуют.
А все const char-ы не придётся пересматривать в таком случае? В случае структур нужно будет переставить местами поля в определении. А если захардкодить — тогда беда.
something_type something_special;
something_special.mean1 = 1;
something_special.mean2 = 1;
...
memcpy(something_dst, something_special, sizeof(something_special));
А ещё, скажу по секрету, для этих действий можно сделать функции с говорящими названиями, и абстрагироваться от внутреннего устройства, если, конечно, хочется грасоты.
Это маска, а не биты. Вы просто забыли, что такое маска или вам никогда ей не приходилось пользоваться.
>А все const char-ы не придётся пересматривать в таком случае?
Константы в одном месте и их не так много. Это не весь гигантский код проекта пересмотреть. За этим константы и заводят, для легкости рефакторинга.
>something_special.mean1 = 1;
something_special.mean2 = 1;
Я уже сказал, что это не удобно и требует изменять код в многих/нескольких местах в случае необходимости каких-то изменений.
>memcpy(something_dst, something_special, sizeof(something_special));
Так отправлять данные в порт ввода/вывода нельзя.
>А ещё, скажу по секрету
Я уже это сказал много выше.
Это мощно.
something_special создаётся в одном месте, потом используется по мере необходимости.
А с memcpy косяк, да. Действительно же нельзя так в порт. Ну вот, вся затея к чертям, увы мне.
Только...
если...
может быть...
... out вместо memcpy?... нет, это было бы слишком очевидно.
Ах да, у out же нет третьего параметра. Опять ничего не получается, обидно.
Если вы не поняли, то я говорил про маску информационных битов, а не про информационные биты.
да, 0b.... было бы замечательно, но его нет. Увы. Но можно и вот так. Ага.
Я уже показал, что это не работает нормально с разнесенными битами одного устройства.
Требует приведений типов, что костыльно, если можно было сделать по человечески.
Он отправляет только целочисленные типы, а не структуры.
Вообще, обычно он не используется в мк, а порты оформляются в виде переменных целочисленного типа для удобства.
> использовать как низкоуровневый язык для контроллеров...
Ты уж определись - либо к умным, либо к красивым.
вот как интеллигентно обозвать мартышкой = )
И туда и туда. Какие у тебя противоречия возникают? Сделать при программировании контроллера более читабильный код, если это не повредит производительности, можно и нужно.
Красота ещё и улучшит производительность. Посмотри на код выше - там строка, а это уже идиотизм. Пришлось придумать такой костыль какому-то говнокодеру. Это на скорости\памятипотреблении микроконтроллера только бы отрицательно сказалось.
Ага, и спасет мир... Знаем, плавали. Понимабельность низкоуровневого кода улучшают комментарии и только они. А строка Bin<101110101101010> выглядит столь же красиво и понятно как и 0b101110101101010 или 0x5D6A. И если у тебя в коде объявлено столько констант, что перевод их в другую систему занимает больше времени, чем флейм здесь, то архитектору нужно руки оторвать. Не, ну серьезно - в этой теме текста в 100500 раз больше, чем в perl-скрипте, который бы перевел все константы в исходниках из вида 0bXXXX... в вид 0xXXXX... (если компилятор на это не способен).
Про самодокументирующийся код не знаете? ок.
>А строка Bin<101110101101010> выглядит столь же красиво и понятно как и 0b101110101101010 или 0x5D6A.
Ну Bin<101110101101010> это костыль, поэтому я не предлагаю его использовать. Нужен просто нормальный стандарт языка, дабы исключить такие костыли.
>И если у тебя в коде объявлено столько констант, что перевод их в другую систему занимает больше времени, чем флейм здесь, то архитектору нужно руки оторвать.
Это верно только для высокоуровнего кода, а не для кода для мк.
>perl-скрипте, который бы перевел все константы в исходниках из вида 0bXXXX... в вид 0xXXXX...
Тоже костыль.
>(если компилятор на это не способен).
Да в том то и проблема языка.
Но автора данного ГК я не оправдываю.
Знаю, пишу. Ынтерпрайз сектор, где накладные расходы на красивую архитектуру бизнес-логики пренебрежимо малы по сравнению с основными задачами.
> Да в том то и проблема языка.
Прежде всего, это проблема того, кто делает из этого проблему. Лично я предпочитаю задавать битмапы hex-ом, даже если пишу под gcc. Это даже удобнее, ибо биты сразу рабиты на блоки по 4.
А говорите в комменте выше так, как будто не знаете.
>накладные расходы на красивую
Только не нужно мне говорить, что из-за 0b011001 возрастут накладные расходы. Они возрастают, если писать так, как написал автор данного говнокода.
>я предпочитаю задавать
Это, исключительно дело вкуса и выполняемых вами задач.
>Это даже удобнее, ибо биты сразу рабиты на блоки по 4.
Это далеко не для всех задач удобно. Часто в мк io-порт делится не на 2 части.
Это же Си!
ТОЛЬКО ХАРДКОД!!! ТОЛЬКО ХАРДКОР!!!
>написать LL в конце?
>число из говнокода можно определить не менее чем тремя другими способами
Зачем говорить очевидные вещи? Я знаю, что автор кода - говнокодер.
Обычно только тупые делают ту работу, которую можно автоматизировать.
Да на С++ то ладно, через шаблоны. Ещё возможно. Но вот на C для контроллеров то как быть? Хотя, как я уже и говорил, в одном компиле я видел библиотеку костыль на макросах, что позволяла записывать в бинарной форме числа, но если это так нужно, то зачем костыли? Не помню, как там это было реализовано и как это можно использовать.
>compile-time переводчик?
Пример приведете? Что-то типа: Bin<UINT64,'1','0','0','1'...> ? Неудобно же. Прятать в макрос? Все равно это в лучшем случае Bin(UINT64,1,0,0,1...). Неудобно.
Bin<10111010,01101010> и т.д., параметров может быть и разное кол-во.
Согласен.
Для исправления этой оплошности как раз и предложили написать Bin<...> (естественно, написать его нужно правильно).
http://pastebin.com/L86GBMYq
продолжение доделайте сами, у меня короткий день
Ты понял соль. Я о том же. А ведь банально можно было добавить в язык 0b101011
2)На С++ микроконтроллеры тоже программируют, на тот случай, если ты ещё не знаешь.
Это очевидное решение, которое первым приходит в голову, но это не удобно. За меня такое вполне может сделать компиль.
>бинарное значение можно в комменте дописать.
Ага, а после рефакторинга бинарное значение в комменте начнет отличаться от реального и будешь ловить ошибки и батхерт, пытаясь найти место появления ошибки.
ругайте
http://pastebin.com/seuTAXR6
Кроме ацма MSC 51 ничо не вспоминается.
&Bxxx - двоичные,
&Oxxx - восьмеричные,
&Hxxx - шестнадцатеричные.
И, как уже было тут упомянуто, в некоторых компиляторах c/c++ это есть, например, в Tiny C.
это багминот так приветствует
ВОН!