Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Geek Culture / Double representation in binary

Author
Message
Michael P
19
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 26th Feb 2012 22:00
Link
I've got quite a unusual task - I want to transfer a double between a java application and a C++ application, where the compiler of the C++ application is not defined.

So the best way to do this to avoid expensive conversions is binary, by transferring the raw 8 bytes of the double.

However, can I guarantee that they are represented the same in both applications such that the conversion will never fail?

From briefly googling I found that C++ and java both use IEEE 754 representation of doubles, and this is defined in their specification. But a colleague of mine told me that he knows of a C++ compiler which represents doubles with 10 bytes instead of 8, so therefore that compiler would basically be broken since its not following the spec? Or alternatively I am wrong, and it is not guaranteed to represent doubles in a set way?

What do you think...

DarkNet - multiplayer plugin
Back to top
Profile PM Email
Diggsey
19
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 26th Feb 2012 22:23 Edited at: 26th Feb 2012 22:24
Link
The only guarantees a C++ compiler has to make are that long double >= double >= float. On the other hand, practically all compilers (99.9%) follow the convention that float = 32-bit, double = 64-bit, long double = either 64-bit or 80-bit. Is it really of much benefit to have it compile without changes on the obscure 0.1% of compilers? You should be more worried about platforms which don't support floating point operations at all.

One interesting thing is that when returning a floating point type, in practially all calling conventions it is left on the FPU for speed, and that will always be in the machine's native format, so when you come to take it back from the FPU it doesn't matter what floating point format you use because the format only affects how it is stored back into RAM, not how the FPU stores it.

[b]
Back to top
Profile PM Email Website
Neuro Fuzzy
17
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 26th Feb 2012 22:52
Link
I've looked into this before. NO DICE!

Really, you just have to make it usable for all practical purposes.

Also, if you're not aware, java=big endian, C++=little endian (errm, although not necessarily?)

Back to top
Profile PM Email
Michael P
19
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 26th Feb 2012 23:22
Link
Sounds like this is not trivial

It would be possible to write something on the C++ side which will convert the java binary into the correct form, but this would be too hard to test - maybe boost has something that can do this already?

The only alternative I see is to convert to/from text string. I think C++ can do this very fast but java is quite slow, but hopefully fast enough.

DarkNet - multiplayer plugin
Back to top
Profile PM Email
Diggsey
19
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 27th Feb 2012 00:00
Link
Have you tried looking at the java native interface? That should have all you need to safely interact with java code.

[b]
Back to top
Profile PM Email Website
Neuro Fuzzy
17
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 27th Feb 2012 00:00 Edited at: 27th Feb 2012 00:02
Link
I wrote a minecraft file parser a while back in C++, and I had to convert everything because it was all stored in big endian. All I had to do was something like:



[edit]
and I admit... I started worrying about the same thing and compatibility issues... but then said screw it because what I had worked and I don't think we're going to switch to 17 bit computers any time soon.

Back to top
Profile PM Email
Back to top

Login to post a reply

Server time is: 2025-05-19 16:18:07
Your offset time is: 2025-05-19 16:18:07