kgabis/parson

Integer get/set

sgh opened this issue · 10 comments

sgh commented

It seems to me that integer get/set functions are missing. Why is only double available?

Why not just do the cast from double to int yourself?

sgh commented

That is possible, but a double cannot consistently hold an int64 value. Most other api's have a distinction between floating points types and integer type of this exact reason.

I can do the implementation if you will accept the change after review.

Please have a look at #134, I'm not planning to add big integer support.

sgh commented

regular int32 then ?

But why? I can understand people making a case for int64, but int32 can easily fit within a double.

sgh commented

Casting from double<->int is as far as I know not 100% safe on all platforms. In any case it is safe if an actual integer type could be supported. As far as int64 goes - for my application - I use parson for both get and set, so compatabillity is not an issue for my isolated case.

Could you provide more info about it? Because it's the first time I hear it's not safe and I'm having trouble thinking about a failure mode here.

sgh commented

Well ... for int32 and uint32 it will work, but at some point it falls apart (above 32 bits), and the exact point where that happens is not clear. The advantage of an integer interface is that the symmetry is perfect and deterministic. This is not the case when casting between integer types and double. There is a minor performance issue as well (I have not measured that).

Also as stated earlier. Most if not all interfaces that deal with these kind of thing have separate floating point and integer functions. They likely have that for a reason, even if the reason is pure cosmetic.

Sorry, I don't follow. Casts between floating point numbers and integers are deterministic. I'm not going to extend the api to avoid using (int). Besides, should I add functions for uint as well? What about char and short? uchar and ushort?

I'm locking this conversation because it's leading nowhere.