So I guess having read_signed_int(int bytes) would be enough for now. Adding variants for specific lengths probably doesnt make a huge difference, as most of the runtime is spent in mega_apply and friends, especially when consuming just a couple of bytes.
I like the proposal for using negative lengths for little endian, so I would add that to read_int(int bytes) and read_signed_int(int bytes). I think we dont need explicit fixed length versions.
I personally prefer read_uint vs read_int as it avoids some possible confusion, but having read_signed_int would make it clear, too.
I am traveling right now, so not sure when I will be pushing a branch for those things...
arne
On 09/13/14 21:45, Stephen R. van den Berg wrote:
Per Hedbor wrote:
It would also break hstring reading rather badly, so you would still need the functions to read unsigned numbers internally.
Also, with native integers, as it turns out, it's fairly equal on x86_64 at least, where the integer operations are inlined.
Just add another function to read signed integers.
Shall we rename the read_int* to read_uint* then?
And as for byteorder, just add a switch to switch byteorder if the number of functions needs to be kept down for some reason.
Well, since IOBuffer is for efficiency and not for beauty, I guess it does not matter a lot if there are few or a lot of functions. Whatever is most efficient counts here, I'd say.