On Thu, Sep 11, 2014 at 10:58 AM, Arne Goedeke el@laramies.com wrote:
I think there is a couple of features that would be nice to have in IOBuffer. If there is no objections I would go ahead and add them.
- support for reading/writing signed integers. Not sure about the api,
maybe the current methods should could be renamed read_uint/add_uint instead? The -1 return value also would not work for the read_ methods. The add_int variants actually work fine for signed ints already, due to the cast to unsigned. sprintf()/sscanf() could be used currently but are quite slow.
The returns value is an issue, I guess using UNDEFINED makes sense.
In my "normal" usage I only use the return value for read_buffer and friends however, and then set error mode and just read.
It really simplifies not having to check after each read, I just added the -1 return value since it sort of makes sense. But UNDEFINED should work just as well, really.
And renaming the current ones to read_u* makes sense if we add non-unsigned versions, yes.
And add_int only sort of works, it will break for bignums, and also normal integers if the width > sizeof(INT_TYPE) (the code padds will null characters).
- read_utf8/add_utf8. its not hard to do, quite common and would save
one string creation and copy.
It would be nice to avoid large amounts of code duplication, however.
- reading/writing ieee floats. also handled by sprintf/sscanf, but on
most systems would reduce to bswap+memcpy
That might be useful, yes. But is it really _that_ common? I guess it makes since to be complete(ish). :)
- little endian support? Admittedly the use cases are narrow for
network protocols, but not so much for file formats.
I avoided that since my point of view when initially implementing the buffer was that it was mainly going to be used for network I/O. But it does work for normal files as well, so it might indeed be useful.
arne