Serializer value() size auto-deduction about bitsery HOT 6 CLOSED

This is a fundamental design decision, for cross-platform compatibility.
This is essential when serializing common types such as int, long, because these types can have different size depending on the platform.

from bitsery.

Well ok, long is platform dependent...
Why one can't just use int32_t, int64_t instead? They should be fixed sized.
And what about float/double?

from bitsery.

You should use int32_t or int64_t, but I cannot enforce it, these are alias types for fundamental numeric types (e.g. int_64t might be an alias for long or long long depending on platform.
Same with float types

from bitsery.

You should use int32_t or int64_t, but I cannot enforce it

I personally disagree that you should try to enforce it at library level... But that is my personal opinion.

Same with float types

There is aliases for floats? float/double have platform dependent size?

from bitsery.

The problem is that it is impossible to enforce to use int_32t or int. If it would be possible, then I would provide different alternatives for int_32t and int. For example: in Rust isize and i32 are different types, and float/double is IEEE 754 compatible.
Am glad that atleast in C++20 signed integers are now two's complement,
Float-types are even more trickier, theirs value representation is implementation defined, it is not even specified if they should be IEEE 754 compatible, although there are trait in numeric_limits to check if its compatbile or not is_iec559. What makes them worse, that even if they are ieee 754 compatible, it still doesn't mean that their representation would be the same on different platforms!
So my advice would be, that if you want to support all-kinds of exotic platforms, you should "quantize" all floating-point types, for example using ValueRange extension, or provide a tests so specifically for floating-point types.

from bitsery.

Hmm, I see...
I didn't thought that on modern CPUs, floats can have different representations...

from bitsery.