Я экспериментирую с некоторыми идеями, согласно которым алгоритмы должны работать с битами как с наименьшей единицей информации. Это модульное приложение, в котором пользователь может переупорядочивать части «конвейера», подобно конвейеру оболочки unix. Эти алгоритмы выполняют различные функции, такие как кадрирование, сжатие, распаковка, проверка и исправление ошибок; введение, обнаружение и удаление шума и т. д.
Так как они работают на битовом уровне, алгоритмы могут, например, принимать 5 битов на вход и выдавать 19 бит на выходе. Ввод и вывод редко бывают кратными байтам.
Работать с потоками битов в памяти и между потоками можно с помощью std::vector<bool>, но мне нужно извлекать и сохранять этот поток битов откуда-то и куда-то, и желательно, чтобы можно было выполнять настоящие конвейеры командной строки, например:
prog1 < bitsource.dat | prog2 -opts | prog3 -opts > bitsink.dat
Или даже:
prog1 | prog2 | ssh user@host /bin/sh -c "prog3 | prog4 > /dev/dsp"
Проблема заключается в том, как эффективно сериализовать эти биты, поскольку стандартные потоки (stdin и stdout) ориентированы на байты. Мне приходится обрабатывать ситуации, когда количество битов на входе и выходе не кратно байту.
В настоящее время у меня есть рабочее доказательство концепции, которое делает это, расширяя каждый бит до байта, который имеет значение 0x30 или 0x31 ("0" или "1"). Очевидно, что это увеличивает размер данных в восемь раз, потребляя в 8 раз больше места и полосы пропускания, чем необходимо. Я хотел бы, чтобы эти биты были упакованы более эффективно.
Одной из альтернатив, которые я рассматриваю, является протокол, который буферизует биты на выходе и создает блоки, состоящие из заголовка Length, за которым следуют ceiling(Length/8) байты данных. , очищая вывод при необходимости.
Но вместо создания выдуманного-протокола хотелось бы узнать, были ли уже у кого-то такие требования, каков ваш опыт, и есть ли уже какой-то стандартный протокол для этого (сериализация произвольного количества бит), который я мог бы использовать. Возможно, у кого-то уже была эта проблема, и он уже использует какую-то форму кодирования, которую также можно использовать в этом приложении, чтобы избежать распространения несовместимых форматов.
