В реальном мире достаточно часто нужна высокая производительность. К примеру, чтобы разгрузить сервера - вместо JSON передавать компактный и умный бинарь. Ускорить обработку данных, храня их не в виде текста, а в виде умного бинаря со структурой, оптимизированной под те операции, которые нужны для данной задачи. Сейчас с форматами не заморачиваются, потому что это сложно. У меня это будет проще простого и можно выжать производительность. Можно будет писать программы, которые не потребляют практически никакой памяти за счёт того, что работают с файлами и потоками напрямую без хранения промежуточных данных в оперативке.
Я пока ещё не продумал API, но будет что-то типа такого:
struct Vec3
{
float x, y, z;
DATAVOLN_ADD_FIELD_REFLECTION(x, y, z);
};
struct Vertex
{
Vec3 Position;
Vec3 Normal;
DATAVOLN_ADD_FIELD_REFLECTION(Position, Normal);
}
std::vector<Vertex> humanMesh;
DataVoln::OpenFile("file.bdv").DeserializeExpression("HumanMesh", humanMesh);
Предполагается, что файл содержит структуру с полем HumanMesh, которое является коллекцией структур, имеющих поля Position и Normal. Типы полей являются векторами, содержащими поля с именами x, y, z, причём они могут быть не float, а с фиксированной точкой любой битности - либа сконвертит. Если тип содержимого поля HumanMesh полностью совпадает с типом в C++, это будет простой memcpy. Также же будет API, который может замапить файл в память и использовать напрямую без копирования.
Итак, из этих 2 строчек первая - это макрос, который добавляет рефлексию в существующую структуру пользователя, а вторая - это команда на десериализацию данных из файла. В других языках, а также когда наконец добавят рефлексию в C++ первая строчка станет не нужна.
Я же говорю, умный формат файла. В нём самом содержится информация о том, что он содержит. По сути описание формата, которое пишет пользователь, конвертируется в компактное бинарное представление и вставляется в начало бинарного файла. В отличие от JSON имена и типы не дублируются, а встречаются ровно один раз. Вот десериализатор будет сверять данные заголовка и данные рефлексии, добавленной в структуру и производить необходимые преобразования, если они требуются.
Перед тем, как выпускать свою идею в свет я сразу определю соглашения о том, поля с какими именами должна содержать структура, чтобы считаться изображением, аудио, видео и так далее. При этом порядок и формат их хранения не важен. Пользователь сможет хранить хоть разные каналы картинки в отдельных массивах, при этом любая другая программа, которая работает с картинками по моим соглашениям, сможет его прочитать.
Перспективы огромные - стираются все границы взаимодействия между разными приложениями, следующими единому соглашению. Они смогут понимать файлы друг друга, даже если у них разный подход к способу организации данных внутри файла, оптимизированный под нужды своего приложения. За счёт унификации данных можно стереть границы между различными языками программирования, организовать удалённый вызов процедур, а в некоторых случаях избежать использования тяжеловесных БД, заменив их просто на файлы.
