Category: литература

Category was added automatically. Read all entries about "литература".

Бритоголовый и С1-97

Волшебные константы, часть 2

Мне так понравилось разнообразие мнений по поводу написанного leetspeak-ом слова Bootload (там, где я спер этот скриншот, срач был под полторы сотни комментов), что предлагаю обсудить вот этот кусок кода, 13 лет в практически неизменном виде существующий в довольно популярном опенсорсном проекте:

Хотя… Пожалуй, обсуждать, по какой причине господин Mathieu Lacage старательно расписал enum для разных значений SUBTYPE_CTL_*** и не стал так делать для SUBTYPE_MGT_*** и SUBTYPE_DATA_*** будет довольно скучно (ответ: потому что мудак), а было бы забавней обсудить, как и почему для того, чтобы два байта отослать — я не вру — вот эти два байта октета:

— надо городить аж вот такую фигню:

uint8_t m_ctrlType;     ///< control type
uint8_t m_ctrlSubtype;  ///< control subtype
uint8_t m_ctrlToDs;     ///< control to DS
uint8_t m_ctrlFromDs;   ///< control from DS
uint8_t m_ctrlMoreFrag; ///< control more fragments
uint8_t m_ctrlRetry;    ///< control retry
uint8_t m_ctrlMoreData; ///< control more data
uint8_t m_ctrlWep;      ///< control WEP
uint8_t m_ctrlOrder;    ///< control order

Вообще, я видел три подхода к проблеме заполнения всякого рода "предопределенных" байтовых и битовых структур на C и C++. Подход первый, расточительный, продемонстрирован только что - заводим по полю избыточного, но удобного размера на каждый элемент структуры, а затем пишем две функции Serialize и Deserialize, в которых занимаемся странным байтоебством примерно в таком духе (да, волшебных констант тут налепили много):

uint16_t val = 0;
val |= (m_ctrlType << 2) & (0x3 << 2);
val |= (m_ctrlSubtype << 4) & (0xf << 4);
val |= (m_ctrlToDs << 8) & (0x1 << 8);
val |= (m_ctrlFromDs << 9) & (0x1 << 9);
val |= (m_ctrlMoreFrag << 10) & (0x1 << 10);
val |= (m_ctrlRetry << 11) & (0x1 << 11);
val |= (m_ctrlMoreData << 13) & (0x1 << 13);
val |= (m_ctrlWep << 14) & (0x1 << 14);
val |= (m_ctrlOrder << 15) & (0x1 << 15);
return val;

Вариант второй - экономично-эмбеддерский, выглядит примерно так:

uint16_t frameControl = 0;
frameControl |= (CTL_TYPE_DATA << FRAME_CONTROL_CONTROL_TYPE_OFFSET) & FRAME_CONTROL_CONTROL_TYPE_MASK;
frameControl |= (CTL_SUBTYPE_DATA_QOS << FRAME_CONTROL_CONTROL_SUBTYPE_OFFSET) & FRAME_CONTROL_CONTROL_SUBTYPE_MASK;

ctrlSubtype = (frameControl & FRAME_CONTROL_CONTROL_SUBTYPE_MASK) >> FRAME_CONTROL_CONTROL_SUBTYPE_OFFSET;
/* and so on */

Отличие от предыдущего - мы работаем напрямую с этими двумя байтиками, и это довольно экономично, нам не надо работать с "тяжеловесным" по эмбеддерским меркам объектом с десятком-другим полей, а то и целой ссылкой на vtable (если обратите внимание - функции Serialize и Deserialize виртуальные). Можно обернуть это все в несколько более удобные макросы или inline-функции.

Но неужели для такой стандартной задачи человечество не придумало ничего лучше? Подобного рода херней люди занимаются вот уже несколько десятков лет, и в полувековой давности языке C есть прекрасная штука - битовые поля. В книжке 1984 года The Unix Programming Environment они описывались, как рекомендованный и правильный способ вот этого битоебства. По удобству это напоминает первый способ, с членами структуры, а по экономичности полностью аналогично второму:

struct {
    unsigned int protocolVersion : 2;
    unsigned int type : 2;
    unsigned int subtype : 4;
    unsigned int toDS : 1;
    unsigned int fromDS : 1;
    unsigned int moreFragments : 1;
    unsigned int retry : 1;
    unsigned int powerManagement : 1;
    unsigned int moreData : 1;
    unsigned int protectedFrame : 1;
    unsigned int order : 1;
} frameControl;

frameControl.type = CTL_TYPE_DATA;
frameControl.subtype = CTL_SUBTYPE_DATA_QOS;

ctrlSubtype = frameControl.subtype;
/* and so on */

Но... если на уровне "байтиков" структуры в C и C++ еще как-то предсказуемы (а проблемы с выравниванием обычно решаются с помощью #pragma pack(1)), то вот битовые поля оказываются настолько непредсказуемы, что в книжке Кернигана и Ритчи приведено осторожное предупреждение, а в любом современном учебнике настоятельно рекомендуется ими никогда не пользоваться!

Что-то мне подсказывает, что вовсе не этого хотели Керниган с Ритчи. А что вы порекомендуете?

Запись опубликована в блоге Шуры Люберецкого. Вы можете оставлять свои комментарии там или в ЖЖ.

Бритоголовый и С1-97

Решил доебаться

Книжка про Natural Language Processing на русском языке. В книжке — ни одного примера на русском:

https://habr.com/ru/company/piter/blog/556140/#comment_23059060

А разгадка одна — проще перевести документацию на русский, чем адаптировать Spacy для русского языка.

Запись опубликована в блоге Шуры Люберецкого. Вы можете оставлять свои комментарии там или в ЖЖ.

Бритоголовый и С1-97

Кстати, вынесу из одного чатика

Обсуждали тут Левенчука (того, который [info]ailev), его книжки и курсы про «системное мышление», и, last but not least, аудиторию этих курсов — которая понабежала к нему во вконтактик и начала высказывать претензии:

https://m.vk.com/wall2449939_3308

Так вот, Левенчук, конечно же, лидер секты — и всем своим поведением демонстрирует именно это — тут и многословие великого Гуру, и постоянно вводимая в книжках и на курсах новая терминология, и сам подход «я вас научу». Но! Само по себе «системное мышление» — в виде некоей недофилософии для инженеров — существует довольно давно, и поверх него построена, например, любимая всем околоайти 34 серия ГОСТов. Так вот, каждый раз, когда я вижу слова вроде «система» и «требования» в какой-нибудь там студенческой работе, например, я плачу кровавыми слезами — люди путают (в ГОСТовских терминах) систему и изделие, требования из ТЗ и решения из эскизного проекта — в общем, совершают полный набор ошибок.

Ценность же системного мышления как недофилософии для инженеров — ровно в том, что оно позволяет четко эти вещи различать, причем не комментируя готовые ГОСТы и подобные стандарты, а предоставляя терминологию для рассуждения о них на более высоком уровне. Но для этого, конечно, нужен определенный жизненный опыт — о чем тот же Левенчук явным образом пишет.

Запись опубликована в блоге Шуры Люберецкого. Вы можете оставлять свои комментарии там или в ЖЖ.

Бритоголовый и С1-97

Учимся программировать под ноотропами

Хотя если вам нужна дополнительная стимуляция для того, чтобы осилить детскую книжку Петцольда — может, не надо?

Запись опубликована в блоге Шуры Люберецкого. Вы можете оставлять свои комментарии там или в ЖЖ.

Бритоголовый и С1-97

The Energy Bus

the-energy-bus

Думал, книжка про одного корейско-русского рокера, вон даже “Икарус” на обложке нарисовали – но нет, это обычное инфоцыганство.

Запись опубликована в блоге Шуры Люберецкого. Вы можете оставлять свои комментарии там, используя свое имя пользователя из ЖЖ (вход по OpenID).

Бритоголовый и С1-97

ООП нужно запретить

Нет, я не про Организацию Освобождения Палестины, я про объектно-ориентированное программирование, которое наносит смертельный ущерб неокрепшим мозгам:

Ну как-то, прочитав книгу Гради Буча, в которой он описывает ООП на аналогии с объектами реального мира, я теперь наоборот, рассматриваю реальный мир по аналогии с ООП.

https://habr.com/ru/post/524718/#comment_22221036

А Гради Буча и его книги следует предать аутодафе по всем правилам испанской инквизиции. Но разумеется, не просто так, а после положенного богословского диспута о Святой Троице, с рисованием UML-диаграмм.

Запись опубликована в блоге Шуры Люберецкого. Вы можете оставлять свои комментарии там, используя свое имя пользователя из ЖЖ (вход по OpenID).

Бритоголовый и С1-97

Переводчики жгут

peery-lea-iot

Сколько раз зарекался читать техническую литературу на русском – столько же раз и жалел об этом. Издательство ДМК-Пресс отожгло напалмом, такого перевода Ready to send и Clear to send я еще ни разу не видел.

Запись опубликована в блоге Шуры Люберецкого. Вы можете оставлять свои комментарии там, используя свое имя пользователя из ЖЖ (вход по OpenID).

Бритоголовый и С1-97

Прочитал тут на днях

В одном околоайтишном чатике:

Слушал я тут как собеседуют devops-ов в core-команду
Конечно, все эти мальчики с татуировками, который умеют yaml-ы писать на первых пяти минутах получат от ворот поворот.
Начинают прямо с азов – как грузится linux, что такое процесс, какие состояния бывают, что такое зомби, чем они плохи, что такое inode, где файл хранится и так далее. Мальчики впадают в какой-то кататонический ступор.

про себя подумал “во валят!” и как-то радостно стало на моей душе

Спрашивают, кстати говоря, действительно не особо сложные вещи – это азы Unix-подобных систем, определения всего этого кочуют из книжки в книжку. Самое древнее, что я читал (гарантированно есть и более “классическая” литература) – это описание 4.3BSD 1989 года, и там все эти вопросы разбираются буквально в первых же параграфах соответствующих глав. Пугает другое – понимая юниксы, можно выучить этот ваш Docker с yaml-ом ну этак за неделю; знающие же только Docker азы юниксов изучать не будут, им это “не нужно”.

Запись опубликована в блоге Шуры Люберецкого. Вы можете оставлять свои комментарии там, используя свое имя пользователя из ЖЖ (вход по OpenID).