Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
Суть теста - есть строка байтов( октетов), нужно узнать равен ли бит на некоторой позиции 1 или 0.
Всё.
У аффтара нумерация байт слева-направо, а нумерация бит в байте справа-налево.
> У аффтара нумерация байт слева-направо, а нумерация бит в байте справа-налево.
Поддержу Кегги. В чем проблема то? Little-endian число первый раз увидел?
>>Ну во-первых в говноконструкторе можно сразу присвоить массив, а не страдать хуйней
ага
и при создании 2 обьектов с одного массива получать побочные явление
А что в коде то не так?
Полное копирование не говно - из контекста не видно. Если ни копировать передается ссылка, может возникнуть побочный эффект.
код внутри нормальный. Нет контекста опять же.
Ну и явное говно одно - не octet а octal
а может на нужно быстро считывать байты? Вот наша задача подразумевает, что нам нужно часто ворочить байты, но иногда нужно обращаться к этой строке как к цельному массиву бит. чем не нравится?
Очередной оптимизатор хуев.
Когда нужно будет быстро - можно оптимизировать.
В первую очередь нужно правильно работать, в соответствии с описанием протокола, а потмо уже быстро.
> в соответствии с описанием протокола
Так все-таки, в каком порядке биты и байты должны лежать согласно протоколу?
Судя по коду, порядок такой:
Нулевой бит - младший бит нулевого байта.
Седьмой бит - старший бит нулевого байта.
Восьмой бит - младший бит первого байта.
Пятнадцатый бит - старший бит первого байта.
Подобный порядок используется очень часто. Но, согласно RFC, должен быть другой?
Octet - это 8 музыкантов или первые 2 катрена сонета. Все, я ушел в шахту, а ты приготовь подробное описание поставленной задачи и мы побеседуем. Лучше - диаграмму классов
> Ну и явное говно одно - не octet а octal
Октет - это восьмибитный байт. Почти во всех RFC так пишут, чтобы всякие педанты не доябывались в духе "а вдруг в моём байте 9 бит?"
Ну а дальше я ничего не понял, полный бред.
Какие-то ненужные манипуляции с длиной массива и 8-кой, побитовое сравнение, упоротый тест.
Всё.
У аффтара нумерация байт слева-направо, а нумерация бит в байте справа-налево.
Поддержу Кегги. В чем проблема то? Little-endian число первый раз увидел?
А то, перевернёшь - и биты уже вне в том порядке.
Кстати, а эта штука участвует в каком-то протоколе с другой прогой, или же ее юзают как банальный BitArray и никогда никуда не передают?
P.S. А почему автор пишет свой велосипед, а не поюзал какую-нибудь готовую либу? Разве под шарп нету либ для SNMP клиентов/серверов?
Только велосипеды!
ага
и при создании 2 обьектов с одного массива получать побочные явление
Полное копирование не говно - из контекста не видно. Если ни копировать передается ссылка, может возникнуть побочный эффект.
код внутри нормальный. Нет контекста опять же.
Ну и явное говно одно - не octet а octal
Т.е. бит №14 равен 0, а бит №8 равен 1?
Дайте мне пепла.
Скажи про бит №14 и бит №8!!!
тут мы идем по первому байту от младшего бита к старшему. затем по второму также от младшего к старшему
так тебя устроит?
Когда нужно будет быстро - можно оптимизировать.
В первую очередь нужно правильно работать, в соответствии с описанием протокола, а потмо уже быстро.
Так все-таки, в каком порядке биты и байты должны лежать согласно протоколу?
Судя по коду, порядок такой:
Нулевой бит - младший бит нулевого байта.
Седьмой бит - старший бит нулевого байта.
Восьмой бит - младший бит первого байта.
Пятнадцатый бит - старший бит первого байта.
Подобный порядок используется очень часто. Но, согласно RFC, должен быть другой?
Что, кто-то спрашивал чье-то мнение по этому протоколу?
Порядок - прямой, без выебонов [0, 1, ...,7],[8, 9, ..., 15][16, 17, ... 23], ... .
Новость для парниши оказалась неожиданной 🙂
SNMP называет именно так.
Октет - это восьмибитный байт. Почти во всех RFC так пишут, чтобы всякие педанты не доябывались в духе "а вдруг в моём байте 9 бит?"
Как можно упароцца так?
m)
блеванул
Американская.
не стертор это