On 2015-01-24, Stefan Bodewig wrote:
> On 2015-01-23, Emmanuel Bourg wrote:
>> - BitInputStream: why not using a long cache instead of an int, like
>> BitStream before the refactoring? It might be interesting to do some
>> benchmarks and see if it make a difference.
> We never needed more than 3
On 2014-11-13, Damjan Jovanovic wrote:
> On Wed, Nov 12, 2014 at 8:51 PM, Stefan Bodewig wrote:
>> One thing BitStream and BitInputStream have in common is what happens
>> when I request more bits than are available from the underlying stream,
>> both will signal an EOF and discard the cached bi
On 2014-11-12, Emmanuel Bourg wrote:
> Le 12/11/2014 19:51, Stefan Bodewig a écrit :
>> A while ago I had already added a guard to ensure nobody tried to read
>> more than 32 bits since bits are accumulated inside an int - but
>> actually we can't do that as readBits returns -1 on EOF, so we can'
On Wed, Nov 12, 2014 at 8:51 PM, Stefan Bodewig wrote:
> One thing BitStream and BitInputStream have in common is what happens
> when I request more bits than are available from the underlying stream,
> both will signal an EOF and discard the cached bits. I.e if there are
> still three bits cach
On Wed, Nov 12, 2014 at 9:49 PM, Stefan Bodewig wrote:
> Apart from EOF handling there also is the byte-order case.
>
> As it stands I'll get different bits in LITTLE_ENDIAN order if I read
> eight bits twice or sixteen bits at once, this is now what I'd expect.
> Should byte order imply we are al
Le 12/11/2014 19:51, Stefan Bodewig a écrit :
> A while ago I had already added a guard to ensure nobody tried to read
> more than 32 bits since bits are accumulated inside an int - but
> actually we can't do that as readBits returns -1 on EOF, so we can't
> read more than 31 bits at a time or a v
On 2014-11-12, Stefan Bodewig wrote:
> As it stands I'll get different bits in LITTLE_ENDIAN order if I read
> eight bits twice or sixteen bits at once, this is now what I'd expect.
And it's not true, I just need to think about the returned ints in a
different way, all is fine :-)
Stefan
--
Apart from EOF handling there also is the byte-order case.
As it stands I'll get different bits in LITTLE_ENDIAN order if I read
eight bits twice or sixteen bits at once, this is now what I'd expect.
Should byte order imply we are always reading bytes in chunks of a given
number?
Right now I don'
Hi
I wanted to write a few additional unit test for BitInputStream and
maybe later replace the zip package's BitStream with it (IMPLODE uses
that under the covers).
A while ago I had already added a guard to ensure nobody tried to read
more than 32 bits since bits are accumulated inside an int -
