boost serialization hexadecimal decimal encoding of data

Question

I am new to boost serialization but this seems very strange to me.

I have a very simple class with two members

int number // always = 123

char buffer[?] // buffer with ? size

so sometimes I set the size to buffer[31] then I serialize the class

22 serialization::archive 8 0 0 1 1 0 0 0 0 123 0 0 31 0 0 0 65 65

we can see the 123 and the 31 so no issue here both are in decimal format.

now I change buffer to buffer[1024] so I expected to see

22 serialization::archive 8 0 0 1 1 0 0 0 0 123 0 0 1024 0 0 0 65 65 ---

this is the actual outcome

22 serialization::archive 8 0 0 1 1 0 0 0 0 123 0 0 0 4 0 0 65 65 65

boost has switched to hex for the buffer size only?

notice the other value is still decimal.

So what happens if I switch number from 123 to 1024 ?

I would imagine 040 ?

22 serialization::archive 8 0 0 1 1 0 0 0 0 1024 0 0 0 4 0 0 65 65

If this is by design, why does the 31 not get converted to 1F ? its not consistent.

This causes problems in our load function for the split_free, we were doing this

unsigned int size;
ar >> size; 

but as you might guess, when this is 040, it truncs to zero :(

what is the recommended solution to this?

I was using boost 1.45.0 but I tested this on boost 1_56.0 and it is the same.

EDIT: sample of the serialization function

template<class Archive>
void save(Archive& ar, const MYCLASS& buffer, unsigned int /*version*/) {
    ar << boost::serialization::make_array(reinterpret_cast<const unsigned char*>(buffer.begin()), buffer.length());
}

MYCLASS is just a wrapper on a char* with the first element an unsigned int to keep the length approximating a UNICODE_STRING

http://msdn.microsoft.com/en-gb/library/windows/desktop/aa380518(v=vs.85).aspx

The code is the same if the length is 1024 or 31 so I would not have expected this to be a problem.

Answer 1

I don't think Boost "switched to hex". I honestly don't have any experience with this, but it looks like boost is serializing as an array of bytes, which can only hold numbers from 0 through 255. 1024 would be a byte with a value 4 followed by a byte with the value 0.

Answer 2

"why does the 31 not get converted to 1F ? its not consistent" - your assumptions are creating false inconsistencies. Stop assuming you can read the serialization archive format when actually you're just guessing.

If you want to know, trace the code. If not, just use the archive format.

If you want "human accessible form", consider the xml_oarchive.