всем доброго дня.

написал свою сериализацию.
встала следующая проблема. при сериализации, к примеру, size_t, размер которого 4 байта, и при попытке десериализовать его в, к примеру, uint64_t, получается очень трудно уловимая ошибка.
сериализация определяет, является ли тип POD-типом, и если да, то тип сохраняется в поток байтов путем взятия его адреса и sizeof(type). при десериализации так же, из потока байтов читается кол-во байт равное sizeof(type). так что, не сложно представить что произойдет, если записать в поток size_t и пытаться прочитать его как uint64_t.

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

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

спасибо.

а как boost serialization с этим справляется ?

mes, это очень сложно понять. мало того что просто разбираться в чужом коде не просто, так там еще и куча препроцессорного кода  
я по началу пытался некоторые моменты понять из нее, но потом забросил..

Добавлено через 2 минуты и 32 секунды
тут вариант надумался еще проще.. вместо того чтоб идентифицировать типы, нужно просто для POD`ов, предварительно записывать их размер.. это как вариант.
т.к. с не POD`ами подобной проблемы быть не может.

а в первом посте разве не то же самое написано ?:


Добавлено через 1 минуту и 27 секунд

можно косвенно, изучив последовательность байт после сериализации нескольких простых типов..

Добавлено через 1 минуту и 49 секунд

почему ?

нет.
там описано как любой POD сохраняется. а я предлагаю перед записью самого POD`а, записывать его размер. а потом его.

но тут еще мысля появилась... для такого способа, кажется разумным будет для записи размера POD`а использовать однобайтовое значение. т.к. все натуральные POD`ы не могут быть больше 256. в таком случае, встает еще один вопрос: не натуральные POD`ы, т.е. структуры, ведь могут быть большими. так что, для записи размера пода использовать 32ух битное значение?

Добавлено @ 19:04

для собственных типов, юзер должен(может) сам описать способ сохранения/восстановления: http://liveworkspace.org/code/53266d05ae88...d597a194f4e99b7
и если сериализация будет проверять размеры для POD типов, то у юзера никаких проблем не может возникнуть... по идее 


Это сообщение отредактировал(а) boostcoder - 14.5.2011, 17:08

нда, как всегда, невнимательно читая пост, подумал, что это у Вас уже есть, но не хватает...  

Добавлено через 1 минуту и 44 секунды


понял о чем Вы, но Вы используете слово POD не в общепринятом смысле..   



Это сообщение отредактировал(а) mes - 7.5.2011, 19:06

?

Добавлено через 44 секунды
ааа.. Вы о том, что POD - это встроенный тип?

это как раз исходили из Вашего контекста, на самом деле это не так 

Добавлено через 1 минуту и 21 секунду
т.е. POD это не только встроенные типы, и указатели,  а также некий ряд пользовательских типов..

в общем, я говорю о встроенных типах)

если я все правильно надумал, то тут нужно такое правило: сколько байт было записано - столько и нужно прочитать. вне зависимости от размера типа в который пытаемся сохранить.

имхо, если размер для сохранения меньше, то желательно сообщать об этом пользователю.. 

можно assert() выбросить.

Добавлено через 1 минуту и 49 секунд
это все же серьезная ошибка.

в бусте, так же, оказывается нет никакой проверки для бинарных архивов: http://liveworkspace.org/code/8a71f43a88c1...0b295cca233924c

Если размер больше, то тоже возможны нехорошие вещи.
напрмер мы сохранили 16 битную переменную short a = -1;
При считывании в 32-разрядную, получим
int a = 0xffff; т.е. 65535 вместо -1

нужно сохранять тогда и знак еще, не толкьо размер.

А вообще лучше сериализовать в текстовый вид. Это поможет избежить таких проблем. К томуже упростятся сразу проблемы с биг/литл эндиэн. 
Ну и если, при десериализации не помещается в переменную, выкидывать исключение.

Это сообщение отредактировал(а) volatile - 7.5.2011, 23:47