Loading files into memory

This is a discussion on Loading files into memory within the C++ Programming forums, part of the General Programming Boards category; I stopped coding for about a year and a half ago. So I'm trying to find things to brush up ...

You can either make a function that reads in the appropriate bits of the struct separately, or you can do something compiler-specific to "pack" the structure together so that there's no padding bytes in it.

it worked, reading it in piece by piece. I wanted to avoid that but meh... actually I did try sizeof(Bitmap_FileHeader) before I just forgot totally about it. I knew it had to do with bytes getting stored in the wrong spot somewhere. For some dumb reason I didn't think "oh my struct is 16bytes and it's only 14bytes"

Anyways, thanks everyone

side note: I'm just practice I/O, I'd like to try loading something like JPEG's into memory once I get a bit better. (eventually for texture mapping in OpenGL). I'd rather texture map other files than uncompressed bmp files. I know I could always use an image library like devIL but I'm just weird =P.

Often times memory is "chunked" into, say, four-byte units, and it's handy for a four-byte thing (like a long, say) to be entirely inside one chunk. So after a two-byte short, the rest of the chunk is unused, so that the next long gets its own chunk (and of course two consecutive two-byte shorts also fill one chunk).

Often times memory is "chunked" into, say, four-byte units, and it's handy for a four-byte thing (like a long, say) to be entirely inside one chunk. So after a two-byte short, the rest of the chunk is unused, so that the next long gets its own chunk (and of course two consecutive two-byte shorts also fill one chunk).

Your statement seems to imply that "anything" has to be aligned to 4 bytes. And it has to do with alignment, but it's a bit more complex than that:
Unaligned memory is where the memory address in bytes is not an even multiple of the size of the type, e.g. 4 bytes for int read from an address that isn't a multiple of 4. A double is usually aligned to 8 bytes (which is also it's usual size).

Aside from CornedBee's correct statement that on some machines, reading unaligned memory [1] can cause crashes. Even if it doesn't cause a crash, it is slower to read memory from an unaligned address (because the processor has to collect data from two separate reads and put it together into one item). So if you have something like this:

Code:

struct X
{
int x;
short y;
int z;
};

then the compiler will pad between the short y and int z so that z is aligned to a multiple of 4 bytes. Most compilers have a way to tell the compiler "don't do that", although sometimes that could cause a crash if the processor doesn't support such things.

Then the compiler will want everything to be a multiplication of 4 bytes? Thus pad the memory with 2 bytes after the short? If it was like:

Code:

struct s {
double a;
double b;
double c;
int x;
double z;
}

Then it would want everything to be a multiplication of 4 bytes or 8 bytes? Thus padding the 4 bytes after x or not?

Can I assume that it is faster by padding the bytes so it can think of the struct in a more "array" way, so knowing the address of the pointer of the struct, find more quickly the values of each member of the struct?