Вообще-то битовое поле в Си определяется стандартно. («Телесистемы»: Конференция «Микроконтроллеры и их применение»)

Вообще-то битовое поле в Си определяется стандартно.

(«Телесистемы»: Конференция «Микроконтроллеры и их применение»)

Отправлено Bill 29 сентября 2005 г. 23:45
В ответ на: А можно ли в С описать битовый массив? отправлено <font color=gray>Ljutik</font> 29 сентября 2005 г. 23:29

Попробуйте так сделать:


typedef unsigned char bit:1;bit   bitarray[10];

Составить ответ ||| Конференция ||| Архив

Ответы

Компилятор ругается. — Ljutik (30.09.2005 00:05 83.237.180.9, пустое)
- Прошу прощения. Ляпнул сдуру. — Bill (30.09.2005 00:13 195.239.108.229, пустое)
- bitfield это элемент структуры, он не может быть новым типом. кроме того type-specifier для битового поля не может быть массивом, только int , long int и т п — DASM (30.09.2005 00:12 217.118.78.1, пустое)
стареешь Bill :-) — DASM (29.09.2005 23:49 217.118.78.1, пустое)
- Наверное, да. Пролетел мал-мал. Но вот так проходит — Bill (30.09.2005 00:09 195.239.108.229, 318 байт)
  - ага. остается добавить функции типа оператора [] произвольного доступа и т п. Варя таким образом кашу из топора изобретаем STL — DASM (30.09.2005 00:21 217.118.78.1, пустое)
    - Зато избегаем извращений - задействования плюсов. :) — SM (30.09.2005 00:23 213.141.159.26, пустое)
      - к счастью использование С постепенно сходит на "нет", иначе и правда первый залетевший дятел разрушил бы цивилизацию — DASM   (30.09.2005 00:26 217.118.78.1, пустое)
        
        Я боюсь, что цивилизацию как раз разрушит плюсплюснутый Си. — Bill   (30.09.2005 00:28 195.239.108.229, пустое)
        
        Именно. И прочее аналогичное (+) — SM   (30.09.2005 00:32 213.141.159.26, 233 байт)
        
        абсолютно непонятное нежелание использовать хорошо проверенную библиотеку и наивно полагать что сам напишешь лучше. Почему бы и транзисторы тогда самому не выращивать ? — DASM   (30.09.2005 00:33 217.118.78.1, пустое)
        
        Хочешь, чтоб что-то было сделано хорошо - делай сам. (с) (Зорг, Пятый элемент) — Крок   (30.09.2005 13:12 213.145.37.233, пустое)
        
        Вот и пришел я к тому, что транзисторы выращиваю (+) — SM   (30.09.2005 00:38 213.141.159.26, 597 байт)
        
        Ответ: — Михаил Е.   (30.09.2005 00:45 83.237.32.94, 254 байт)
        
        Что-то я лично не замечаю. Хотя спектр задач довольно широк, включает всю ЦОС, задачи управления, протоколы связи (не только с компом, а связь вообще), драйвера в PC, моделирование систем... — SM   (30.09.2005 01:00 213.141.159.26, пустое)
        
        Жуть! Покажи хоть, рук своих творение. Хачу узреть профессионала в действии. — undefined   (30.09.2005 08:09 217.29.80.82, пустое)
        
        Что могу показать (+) — SM   (30.09.2005 09:40 213.141.159.26, 755 байт)
        
        Впечатляет. А я вот не могу сказать, вот мол я делал. Так как над каждой железкой по 15-25 человек вламывает. На сегодняшний день только одна железяка где я могу сказть о своём 30% вкладе... — undefined   (30.09.2005 13:58 217.29.80.82, пустое)
        
        Пока ты пишешь свою библиотеку конкурент уже продаст тысячи девайсов и перейдет к новым. Это общая тенденция во всей бытовой и не только техники. Исключения, подтверждающие правила, наблюдаются в застойных крупнотиражных областях. Можешь себе представить сотовую трубку, с софтом на голом С ? Я уже и на ++ не представляю, java всякие и прочее — DASM   (30.09.2005 00:43 217.118.78.1, пустое)
        
        Конкурренция бывает разная (+) — SM   (30.09.2005 00:57 213.141.159.26, 873 байт)
        
        я и говорю "в застойных крупнотиражных" — DASM   (30.09.2005 00:58 217.118.78.1, пустое)
        
        Чего же тут застойного? Прогресс и в таких проектах не меньше движется. Однако все куда более аккуратно - так как главное это не сиюминутное "продал и всё пох", а стабильный и долгий доход. — SM   (30.09.2005 01:03 213.141.159.26, пустое)
        
        попрошу проаргументировать эту точку зрения. Лично мне программы на С напоминают глобальную кашу ф-ций и данных. Потуги программистов хоть как-то их разделить неизбежно приводят к ++ подобному коду — DASM   (30.09.2005 00:32 217.118.78.1, пустое)
        
        Ведь объет это "черный ящик". Его содержимое знает только тот, кто его создал. — Bill   (30.09.2005 00:57 195.239.108.229, 1211 байт, ссылка)
        
        Bill? ты начинался черти чего и, похоже, серъезно не пробовал на ++ писать. Естественно любая сторонняя библиотека должны быть ЧЕТКО документирована в терминах ИНТЕРФЕЙСОВ. И этого более чем достаточно. Никакой легкости создания объектов в ООП нет (+) — DASM   (30.09.2005 01:05 217.118.78.1, 650 байт)
        
        Так я о том и говорю, что требуется АККУРАТНОСТЬ везде. И чем выше уровень, — Bill   (30.09.2005 01:25 195.239.108.229, 1166 байт)
        
        вообще мы от идее разделения код от данных и полиморфизма объектов как-то странно перетекли на библиотеки, которые к С++ вобщем-то не относятся — DASM   (30.09.2005 01:34 217.118.78.1, пустое)
        
        Ну почему же не относяться? Библиотеки компонентов (объектов) — Bill   (30.09.2005 01:48 195.239.108.229, 33 байт)
        
        Да нет, мы с STL начинали... С массива битового. Что есть чиста библиотека. — SM   (30.09.2005 01:36 213.141.159.26, пустое)
        
        Этого недостаточно! Еще необходима гарантия отсутствия ошибок (ха-ха), или хотя бы бесплатного и БЫСТРОГО их устранения. Только тогда можно допустить библиотеку к использованию в проекте. — SM   (30.09.2005 01:08 213.141.159.26, пустое)
        
        Вот именно что БЫСТРОГО. В ++ достаточно исправить ошибку в базовом классе, и все объекты исправлены. Объекты отлаживаются почти независимо друг от друга, т.е. отлаживается сравнительно небольшой кусок программы. А в СИ все взаимосвязанно, там можно по всей программе искать и не найти. Просто СИ++ - это другой способ мышления и для вас с Billом здесь пока психологический барьер. SM, у тебя же голова золотая, попробуй врубиться в ++, ты то сразу все преимущества просечешь. — Михаил Е.   (30.09.2005 01:23 83.237.32.94, пустое)
        
        Барьера психологического нет. Я пока просто не вижу необходимости его использования. — Bill   (30.09.2005 01:27 195.239.108.229, 31 байт)
        
        Да отлично знаю я эти ++, и разбираюсь в них. Не подходят они ни к одной из моих задач. Не делаю я монстров. — SM   (30.09.2005 01:24 213.141.159.26, пустое)
        
        ой, да ладно отлично :-) Его Страуструп отлично то не знает :-D — DASM   (30.09.2005 01:33 217.118.78.1, пустое)
        
        Я хочу сослаться на твой пример с битами. Как все замечательно выглядит в исходном тексте! — Bill   (30.09.2005 01:42 195.239.108.229, 370 байт)
        
        мы не говорим про ATTINY etc. Вот сейчас активно использую stl в LPC2138. 512 к флеша и 32 к рам есть. Рам хотелось бы побольше, но в целом на ++ уже достаточно комфортно. И у меня есть уверенность что этот код будет работать и на любом другом процессоре. — DASM   (30.09.2005 01:51 217.118.78.1, пустое)
        
        Всякому овощу свой фрукт. Я же не против Си++ как такового. Я просто говорю о том, — Bill   (30.09.2005 02:02 195.239.108.229, 332 байт)
        
        И с точки зрения размера поражаемой зоны, Си++ гораздо мощнее — Bill   (30.09.2005 02:10 195.239.108.229, 249 байт)
        
        и опять же за счет механизма обработки исключений и строгой типизации С++ БЕЗОПАСНЕЙ чем С — DASM   (30.09.2005 02:27 217.118.78.1, пустое)
        
        Чем больше разных механизмов, тем больше вероятность того, что они дадут сбой. — SM   (30.09.2005 09:41 213.141.159.26, пустое)
        
        Именно. Лом надежней перфоратора именно из-за простоты конструкции. — †   (30.09.2005 11:20 81.23.109.150, пустое)
        
        PS уже сейчас темпы выхода новых процев таковы, что чем сидеть писать свое под имеющийся проц - быстрее подождать подходящий. Ибо быстрее получится =) — DASM   (30.09.2005 01:52 217.118.78.1, пустое)
        
        И ждать его можно очень-очень долго. Так как подходящих что-то не делают. Вот у холтека например мне вроде подходящий, но дороговат зараза... Быстрее и проц самому сделать :) :) :) — SM   (30.09.2005 01:55 213.141.159.26, пустое)
        
        Ну тут народ уже давно перестал ресурсы считать - не влезет, так проц в два раза толще воткнут :) :) — SM   (30.09.2005 01:49 213.141.159.26, пустое)
        
        Ну, это само собой. Как говорится, сила есть - ума не надо. Только лично мне не хочется — Bill   (30.09.2005 01:55 195.239.108.229, 177 байт)
        
        Абсолютно поддерживаю. Далеко не все (а думаю мало кто) могут пожертвовать N баксов/девайс только ради красоты кода и экономии пары недель-месяца времени. — SM   (30.09.2005 01:57 213.141.159.26, пустое)
        
        Особенно эсли это N твое личное, и идет тебе в карман :) :) — SM   (30.09.2005 01:58 213.141.159.26, пустое)
        
        Да вот только сейчас сообразил, а ведь я пишу на ++ (+) — SM   (30.09.2005 01:35 213.141.159.26, 95 байт)
        
        И красота программы в моих представлениях (+) — SM   (30.09.2005 01:29 213.141.159.26, 153 байт)
        
        :) :) А читаемость кода (+) — SM   (30.09.2005 01:51 213.141.159.26, 101 байт)
        
        ладно. Предлагаю остановится на том, что самый лучший язык - это женский и на этом разойтись =))) — DASM   (30.09.2005 02:12 217.118.78.1, пустое)
        
        гарантию может дать только полис сами знаете чего. Тем не менее документированный (часто объем документации > объема сурцев) код имеет меньше шансов быть ошибочным, ведь его использовали уже десятки фирм и находили и исправляли ошибки. В то время как небольшая фирма не может позволить себе больших затрат на тестирование. — DASM   (30.09.2005 01:12 217.118.78.1, пустое)
        
        Извиняюсь, прочитал плохо. Да, если библиотека поставляется в виде хорошо документированного КОДА, а не интерфейса, то я только за. Такую библиотеку можно самостоятельно исправить, если что. — SM   (30.09.2005 01:21 213.141.159.26, пустое)
        
        Да-да... Конкретный пример GPL-софт. Все кому не лень находят глюки, исправляют, куча патчей выходит, куча веток и полный разброд. Извини, но если я приобретаю либу у фирмы, так пусть она свои глюки исправляет, и гарантирует, что сделает она это в приемлемые сроки. А не десятки фирм. — SM   (30.09.2005 01:18 213.141.159.26, пустое)
        
        для начала хотелось бы посмотреть на библиотеку безглючную общего пользования, которую напишешь ты и твои коллеги — DASM   (30.09.2005 01:20 217.118.78.1, пустое)
        
        Я не буду писать библиотек общего пользования, ибо априори знаю, что безглючность (точнее стремящаяся к нулю вероятность глюка) у нее только в тех условиях, в которой ее оттестировал я. И гарантий на другие условия я дать не могу. — SM   (30.09.2005 01:23 213.141.159.26, пустое)
        
        К еще большему счастью не везде. — SM   (30.09.2005 00:27 213.141.159.26, пустое)
        
        к счастью для дятлов - безусловно — DASM   (30.09.2005 00:28 217.118.78.1, пустое)
        
        Это что - намек? — SM   (30.09.2005 00:33 213.141.159.26, пустое)
        
        ну кому-то то должно быть счастье. С имеет смысл при написании драйверов и очень критичных кусков OC. В иных случаях его применении следует рассматривать как целенаправленное вредительство, направленное на подрыв устоев общества — DASM   (30.09.2005 00:36 217.118.78.1, пустое)
        
        Гхм... К нам в контору народ с таким мировоззрением и за версту не подпустим :) — SM   (30.09.2005 00:39 213.141.159.26, пустое)
        
        как повезло народу, которого не пустили к вам в контору :-) — DASM   (30.09.2005 00:44 217.118.78.1, пустое)
        
        Да уж. Пусть пишут виндовсообразных по глючности монстров. А то в маску такой код засунешь, через полгодика-годик он вылезет... И попадалово во всей красе. — SM   (30.09.2005 01:05 213.141.159.26, пустое)
        
        Ну выпустишь еррату как все пацаны :) — Codavr   (30.09.2005 12:05 193.233.48.103, пустое)
  - Кстати, на глаза попался архив функций для работы с данными типа множеств в Паскале. — Bill (30.09.2005 00:12 195.239.108.229, 62 байт)

Перейти к списку ответов ||| Конференция ||| Архив ||| Главная страница ||| Содержание ||| Без кадра

E-mail: info@telesys.ru