Делаете такую структуру, которая совпадает со структурой вашей программы. Маппите в память файл и сразу работаете без преобразования. Если в новой версии программы структура поменялась, рантайм всё преобразует с потерей производительности и вместо замапленного файла выдаст буфер, в котором данные преобразованы. В этом случае потеря производительности будет, зато всё будет работать.

Big-endian/little-endian anyone? 😉

Я хочу массив 3-битных интов, и хранить его в запакованном виде. Как мне сделать это в protobuf, не программируя запаковку бит в программе?

Little-endian и big-endian уже продуманы, поддерживаются оба.

И выравнивание поддерживается тоже.

Запрограммировать в программе

Не вижу причин выносить упаковку куда-то

Я-то с ProtoBuf не работал, но кто работал наверняка могут с ходу написать спеку, по которой protoc (или как там его) генерирует нужный код запаковки/распаковки. 🤷‍♀️

Программа преобразует данные. БД из хранит. Распределение обязанностей.

Открыть файл, быстро распарсить информацию о типах в начале файла и замапить в память. Будет как flatbuffers.

И как же они поддерживаются так чтобы "маппите в память файл и сразу работаете без преобразования"?

А потом в новой версии программы я решу, что мне надо 5 бит, а не 3. И библиотека сама преобразует старый файл при открытии из 3 бит в 5.

Спасибо, pickle уже показал себя. Не надо нам такого

На Little-endian архитектуре данные будут сериализовываться в little-endian виде, а на big-endian - в big-endian. Если перекинуть BE файл на LE машину и открыть его, библиотека поймёт, что порядок отличается и сконвертит автоматически.

Ну, я смотрю, у Вас всё схвачено. 👍
Главное - инвестора найти. 😊

(Для справки: это была ирония. 😊)

В protobuf, к примеру, не нужно хранить информацию о типах, она хранится в схеме (т.е. в парсере, а не самих данных), поэтому protobuf компактнее, чем форматы, хранящие информацию о типах (sqlite, message pack). Зато во втором случае можно работать с данными, не зная схемы или зная её лишь частично. Json - вообще текстовый формат, его могут читать и редактировать люди в обычном редакторе, зато он намного менее компактный, чем дaже message pack.
Форматов много потому что требования в разных задачах разные. Как вы всё это сможете совместить в одном формате?

Когда всё вместе и в рамках одного языка, получается всё гораздо проще. Сериализация не нужна, потому что сам язык и есть формат сериализации.

Ну если он распишет технически как оно будет работать и это заинтересует какой-то Яндекс то чё нет. Он не этого не сделает, его отошьют когда увидят ТП. Но пусть пробует, нам то что)

То есть я не могу контролировать формат?