Serializer value() size auto-deduction

[tower120]

Probably discussed somewhere before, but.

Serializer have

template<size_t VSIZE, typename T>
void value(const T &v)

why this is impossible:

template<typename T>
void value(const T &v)
{
    value<sizeof(T)>(v);
}

?

Why value size must be always specified?

[fraillt]

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.

[tower120]

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?

[fraillt]

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

[tower120]

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?

[fraillt]

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.

[tower120]

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