InputStream endianess and Float


#1

Hi Guys,

Is there a reason why there is no ReadFloatBigEndian and
ReadDoubleBigEndian ?

Because currently reading a float on a big endian file reads garbage :slight_smile:

By the way,
It would be great if we can set the whole stream as big endian or little endian and only have one kind of read/write functions.
It will be way easier to read as most of the time we don t change endianess in the middle of a stream.
Sure you can’t know at first look what kind of data you are written… but do we really care ?

Thanks,


#2

Reading a float doesn’t produce rubbish…?? The code for that looks fine to me. It casts it to an int and writes it little-endian, so must work the same on any platform…


#3

Well, in facts it’s not defined by the standard.

So it’s a bit file specific.
When I was saying garbage, I was talking about order.
And of course the file I am trying to read use big endian float and I’m on a x86 :slight_smile:

So in theory you can have both.

Thanks,


#4

Ah, well it doesn’t make any guarantees about the data, except that if you write it with writeFloat and read it with readFloat, the same number will come out. If you really need the bytes to be compatible with some other software, then you should probably write the routine yourself.


#5

Yep that’s why providing ReadFloatBigEndian and
ReadDoubleBigEndian would do the job.
You only need to call the right one according to the file spec.
and if you don’t care then you can still call readFloat and readDouble.

I’m not asking for more :slight_smile:

Thanks,


#6

Ok, fair point. I’ll add that.


#7

Thanks


#8

Hi Jules,

please find a patch related to this issue.
http://littlejourney.net/JUCE/juceStreamPatch.patch

I’ve changed the use of int to int32 too.
To be more 64 bits safe.

By the way, I dont understand why functions like readFloat/writeFloat/… are virtual.
Only read and write needs to be virtual. Not the helpers one.

Thanks,


#9

ah, I’d already done this, I’ve just checked it in. Don’t think there’s likely to be a big problem with the ints, because if the compiler decided to make the int 64 bits, pretty much everything else in the library would break!


#10

Thanks,

What about the virtual ?

Regarding int, better sooner than later no ?


#11

It’s virtual in case a subclass wants to implement a more efficient version of the function…

And as for the ints, I really can’t imagine any compiler in the forseeable future changing them to be 64-bit, because almost no software would compile! If there’s ever any danger of that happening, I’ll go through and do a search-and-replace.


#12

My bad I thought OSX ints on 64bits where 64bits.
After checking it’s indeed only long which will be 64 bits.

Thanks,


#13