[baxissimo]

So any thoughts on how to deal with a 64-bit platforms?

I don't have any experience in that area, but from what I understand, the length parameter of an array will be 64-bits on such a platform. I think that's the main thing that will affect serializaition, since no pointers are saved in the stream directly.

But also I think size_t and maybe a handful of other types are different lengths, so anyone who tries to save a size_t on a 64-bit platform and load it on a 32-bit platform is in trouble. It will be saved as ulong, but get loaded as just uint. And there will be 4 extra bytes sitting there in the stream.

For arrays we can do something about it. But for size_t and the like, I don't see how the current automatic approach can deal with that, given that size_t is just an alias.

[aarti_pl]

Well, now I see that it is just a variation on different 'real' size on different platform.

There is no problem with types as arrays e.g. strings because the real length of array is always written in the byte stream. It is somewhat different in case of numbers, as they size is implicitly kept in they type.

So the solution would be to store type size explicitly in stream. Then you have option when deserializing: you can check if stored size is same as your platform type size. If not, you can fail fast or try to convert and throw only when overflow is occurring.

I think it should be configurable through some kind of policy on serializer. Trying to convert should be default I think. And the same applies for reals also, although conversion when sizes differ will be more difficult.

[aarti_pl]

On 8 bits there should be enough place to put length of number (4bits) and also some simple type information (other 4 bits). I mean info about simple types + other in case of e.g. size_t. It should be possible. It will give possibility to do some more checks.

[baxissimo]