#include <boost/archive/binary_oarchive.hpp>
#include <map>
int main(int argc, char** argv)
{
enum class Type : uint8_t {
A = 1,
B = 2,
C = 3,
};
std::map<Type, uint16_t> t1;
t1.insert(std::make_pair(Type::A, 42));
t1.insert(std::make_pair(Type::B, 42));
t1.insert(std::make_pair(Type::C, 42));
std::map<uint8_t, uint16_t> t2;
t2.insert(std::make_pair(1, 43));
t2.insert(std::make_pair(2, 43));
t2.insert(std::make_pair(3, 43));
{
std::stringstream os;
boost::archive::binary_oarchive oa(os);
oa << t1;
std::cout << os.str().length() << std::endl;
}
{
std::stringstream os;
boost::archive::binary_oarchive oa(os);
oa << t2;
std::cout << os.str().length() << std::endl;
}
return 0;
}
Вывод:
80
71
На сколько я понимаю, для контейнера t1 длина ключа 32 бита, вместо ожидаемых 8-ми. Почему так происходит и как добиться чтобы на битовом уровне длина ключа соответствовала используемому типу? Ведь sizeof(Type) == 1.
Здравствуйте, real_sba, Вы писали:
_>На сколько я понимаю, для контейнера t1 длина ключа 32 бита, вместо ожидаемых 8-ми. Почему так происходит и как добиться чтобы на битовом уровне длина ключа соответствовала используемому типу? Ведь sizeof(Type) == 1.
Минус за LMGTFY, три раза.
Во-первых, ссылкосжиматель хорош для твиттера от безысходности, а для интернетов можно и прямую давать.
Во-вторых, грубо!
В-третьих, на поставленный вопрос так и не ответил.
Первые несколько ссылок идут на обычные энумы, у которых underlying type не меньше, чем int. Для них, конечно, надо сделать хак — обёртку с явно перегруженными функциями сериализации через подходящий тип.
Энум-классы же вполне могли бы сериализоваться в правильном типе, но, видимо, буст в этом месте достаточно старый и не поддержал стандарт в полной мере. Как бы, работает — и ладно.
Здравствуйте, Кодт, Вы писали:
К>Во-первых, ссылкосжиматель хорош для твиттера от безысходности, а для интернетов можно и прямую давать. К>Во-вторых, грубо!
согласен, прошу прощения, если обидел ТС или еще кого-то. это скорее из вредности случилось не было очевидно, что ТС прошел по этим ссылкам, чтобы иметь первичное представление о проблеме и способах решения
К>В-третьих, на поставленный вопрос так и не ответил.
тут я не согласен, первая же ссылка содержит помощь. думаю, твое "в-третьих" родилось из первых двух
К>Первые несколько ссылок идут на обычные энумы, у которых underlying type не меньше, чем int. Для них, конечно, надо сделать хак
первая ссылка содержит рекомендацию сделать хак и ничего не советует из буста, что намекает о том, что такова селяви буст
пятая ссылка ведет в бустовый мейл-лист и тоже содержит лишь хак
Здравствуйте, uzhas, Вы писали:
К>>Первые несколько ссылок идут на обычные энумы, у которых underlying type не меньше, чем int. Для них, конечно, надо сделать хак
U>первая ссылка содержит рекомендацию сделать хак и ничего не советует из буста, что намекает о том, что такова селяви буст U>пятая ссылка ведет в бустовый мейл-лист и тоже содержит лишь хак
Ты имеешь в виду их багтрекер — https://svn.boost.org/trac/boost/ticket/9843 ?
Сложилось впечатление, что ответственный за буст.архив просто решил забить болт на "эту новомодную экзотику".
Открыл, закрыл "инвалид", переоткрыл, перезакрыл "инвалид".
Здравствуйте, Кодт, Вы писали:
К>Во-первых, ссылкосжиматель хорош для твиттера от безысходности, а для интернетов можно и прямую давать.
LMGTFY вроде по-умолчанию сжатую выдает.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, niXman, Вы писали:
X>использовать YAS?
Ознакомился. Скорость радует.
Не понял как предлагается решать задачу версионности структур данных?
Здравствуйте, real_sba, Вы писали:
_>Не понял как предлагается решать задачу версионности структур данных?
предполагается, что это решается на уровня пользователя.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
_>>Не понял как предлагается решать задачу версионности структур данных? X>предполагается, что это решается на уровня пользователя.
Пока никак не соображу как это сделать эффективно.
Вносить дополнительную информацию (о версии структуры данных) в протокол вручную? (ИМХО не вариант)
Здравствуйте, real_sba, Вы писали:
_>Вносить дополнительную информацию (о версии структуры данных) в протокол вручную? (ИМХО не вариант)
у нас, клиент, при подключении, первым делом сообщает серверу поддерживаемую версию протокола. и все, дальше сервер переключается на нужную версию.
никакого отдельного поля для каждой структуры.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
вообще, мы от этого пытаемся избавиться, путем принудительного автоапдейта клиента, по двум причинам:
1. держать несколько ветвей кода для версий API+данных — неразумно.
2. у нас никогда так и не было более одной версии данных. API+данных устаканиваются до релиза проекта.
но все зависит от задачи. в геймдеве, в наших проектах, нам так проще.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>вообще, мы от этого пытаемся избавиться, путем принудительного автоапдейта клиента, по двум причинам: X>1. держать несколько ветвей кода для разных версий API+данных — неразумно. X>2. у нас никогда так и не было более одной версии данных. API+данные устаканиваются до релиза проекта.
X>но все зависит от задачи. в геймдеве, в наших проектах, нам так проще.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
вот так:
вообще, мы от этого пытаемся избавиться, путем принудительного автоапдейта клиента, по двум причинам:
1. держать несколько ветвей кода для разных версий API+данных — неразумно.
2. у нас никогда так и не было более одной версии API+данных. API+данные устаканиваются до релиза проекта.
но все зависит от задачи. в геймдеве, в наших проектах, нам так проще.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>у нас, клиент, при подключении, первым делом сообщает серверу поддерживаемую версию протокола. и все, дальше сервер переключается на нужную версию. X>никакого отдельного поля для каждой структуры.
С точки зрения сетевого взаимодействия, когда необходимо одновременно поддерживать разные версии протокола — самое оно.
У меня же много проще случай. Данные сериализируются только для хранения (извне). Используется ленивое обновление на более новую версию (при первом сохранении объекта). Данные во внешнем хранилище могут сколько угодно долго находиться в одном из старых форматов, пока случайно лениво не обновятся, либо пока не приспичит и будет принудительно запущена процедура перехода на последнюю версию (после этого на сервере убирается поддержка более старых форматов). Суть — один в один согласно идеологии boost::serialization.
ну...если хранимые типы данных между собой не связаны, и их большое кол-во — то для каждого типа/стркутуры можно сохранять версию отдельным полем, и, агрегировать сериализатор/десериализатор.
нужно больше информации, чтоб понять проблему...
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Перекуём баги на фичи!
не было очевидно, что ТС прошел по этим ссылкам, чтобы иметь первичное представление о проблеме и способах решения
