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.

You should show the code that's performing the serialization. — Steve, Nov 14 '14 at 15:37
Edit your post and put that code up there. Make sure it's indented four spaces and it should be syntax highlighted as well. It'll make it easier for people to read and more likely for people to help. — Steve, Nov 14 '14 at 15:54
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`. — Steve, Nov 14 '14 at 16:00
Hi Steve you are correct. I assumed the 04 00 was 400 hex which would be 1024 but it like you said, its actually the byte array... I should have tried some other numbers... I can fix it now. Thanks — , Nov 14 '14 at 16:33
I re-posted my comment as an answer, if you would like to accept it as such :) Thanks. — Steve, Nov 14 '14 at 17:38

score 0 · Answer 1 · answered Nov 14 '14 at 16:18

"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.

score 0 · Accepted Answer · answered Nov 14 '14 at 17:37

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.

boost serialization hexadecimal decimal encoding of data

2 Answers2