boost serialization set Max version

Если ты переносишь данные между машинами, то лучше вообще не использовать boost Serialization, т.к. он не умеет создавать независимые от архитектуры бинарные архивы. Вот хорошая альтернатива: http://uscilab.github.io/cereal/

А почему могут быть проблемы? Я сериализирую изображение с вебкамеры. OpenCV вычитывает, если клиет подключен - другой поток сериализирует и отправляет (используя boost asio) клиенту.

С orangepi (ubuntu, версия не помню, boost 1.54, версия сериализатора: 10) к gentoo и к ubunta (16.04, boost 1.58) работает.
Возможно из-за порядка байт?

порядок байт непричем. там просто проверка версии. С 95% вероятностью для тебя ее можно отключить.

смотри тут http://www.boost.org/doc/libs/1_62_0/libs/serialization/doc/traits.html#tracking

А вообще я в свое время отказался от бустового в пользу протобуфера.

А почему могут быть проблемы? Я сериализирую изображение с вебкамеры.

В общем случае - из-за порядка байт и из-за размеров типов данных (помнится, наступил именно на эти грабли с бустовой сериализацией при пересылке данных между виндой и линуксом на машинах с amd64 и i586 архитектурами, после чего её и выкинул). А тут ты меня вообще сразил наповал: сериализовывать изображение с веб-камеры бустом - это сильно. Но даже если согласиться, что это нормально, то всё равно Cereal лучше, ибо гораздо быстрее.

boost serialization - кусок говна именно из-за непостоянности формата между версиями. Потому выкидывай его нафиг и меняй на что-то нормальное.

З.Ы. protobuf хорош, но имеет некоторые проблемы с производительностью.

Там не только изображение, а и другая информация. Взял его, так как встречался с им.

Я там сохраняю std::string, int, void *.

А зачем для таких мелочей вообще внешняя либа? Оно ж руками делается.

boost уже в зависимостях.

Я уже сказал - boost serialization сжечь нахер. Он с нестабильным ABI просто неюзабелен. На этом вопрос по бусту закрыли. Остаются или другие либы, или руками.

Глупый вопрос. Будет ли это платформонезависимым?

int i; 
std::string str;

std::stringstream stream;
stream << i << " ";
stream << str.size() << " " << str;
return stream.str();

std::stringstream

Брось каку.

Подскажите как лучше. И чтоб переносимое было.

_если_ ты точно знаешь, что всё, что тебе надо - это всего int + string + blob, то пишешь говнокодом в лоб, используя платформенно-независимые типы:

std::string str = ...;
int32_t i = ...;
std::vector<char> buf = ...;

size_t size = sizeof(uint64_t) + str.size() + sizeof(i) + sizeof(uint64_t) + buf.size();

std::unique_ptr<char> data(new char[size]);
char* ptr = data.get();

memcpy(ptr, static_cast<uint64_t>(str.size()), sizeof(uint64_t));
ptr += sizeof(uint64_t);
memcpy(ptr, str.c_str(), str.size());
ptr += str.size();

memcpy(ptr, i, sizeof(i));
ptr += sizeof(i);

memcpy(ptr, static_cast<uint64_t>(buf.size()), sizeof(uint64_t));
ptr += sizeof(uint64_t);
memcpy(ptr, &buf[0], buf.size());
ptr += buf.size();

writefile(data.get(), size);

На endianness забиваешь, пока реально в твоей жизни не появится полумертвая платформа, где endianness другой. Да и buf небось у тебя тоже зависит от endianness.

Этот говнокод лучше чем тормозной stringstream за счет минимального кол-ва аллокаций памяти/копирования.

std::unique_ptr<char> data(new char[size]);

Надо char[]: std::unique_ptr<char[]> data(new char[size]);

Или: auto data = std::make_unique<char[]>(size);

На endianness забиваешь, пока реально в твоей жизни не появится полумертвая платформа, где endianness другой. Да и buf небось у тебя тоже зависит от endianness.

Так человек же про OrangePi написал, а разве там не ARM с BigEndian?

Так человек же про OrangePi написал

Опа, пропустил мимо ушей.

а разве там не ARM с BigEndian?

А хз.

Надо char[]:

Для char пох, хотя конечно ты прав.