views:

56

answers:

1

I"m planning to store my data in a binary format as a resource, read it into an int buffer and basically pass it straight down to a native C++ function, which might cast it to a struct/class and work with it. No pointers, obviously, just ints and floats.

The question is - what kind of fixing up do I need to do? I suppose that I need to check ByteOrder.nativeOrder(), figure out if it's big endian or little endian, and perform byte-swapping if need be.

Other than that, floats are presumably guaranteed to be expected in IEEE 754 format? Are there any other caveats I'm completely overlooking here?

(Also - since I'm compiling using the NDK, I know what architecture it is already (ARMv7-A, in my case), so can I technically skip the endian shenanigans and just take the data the way it is?)

+2  A: 

ARM support both big and little endian. This will most probably be set by the OS so it might be worth while checking this out beforehand.

There is also the issue of padding to word size in a struct:

struct st
{
  char a;
  int  b;
};

will have a sizeof 8 and not the expected 5 bytes. This is so that the int will be word aligned. Generally align everything to 4 bytes and probably use the gcc packed attribute (struct my_packed_struct __attribute__ ((__packed__)) ) as well. This will ensure that the internals of the struct are as you expect.

Alternatively use the Android Simulator to generate the data file for you.

doron
In this particular case, I'm only using native types with a size of 4 bytes (I won't entertain the idea of a 64-bit int on ARM for now), and I won't even dream about 128-bit VMX registers for now, so I should be fine in that regard. (Besides, I generally try to avoid any kind of implicit padding in my structs - if I really have tom then I add a char m_Pad[3] to make it clear there's padding so I can fill it out later if I add variables.) As for floats: No worries there since IEEE 754 basically guarantees the same format, right?
EboMike