Thread: How is data stored? (or something like that)

Hey guys, if I did this:

Code:

unsigned char *foob;
foob = new unsigned char[4];
foob[0] = 0x10101010;
foob[1] = 0x11111111;
foob[2] = 0x00000000;
foob[3] = 0x01010101;

unsigned long boof;
boof = *(unsigned long*) foob;

What would the boof's bits look like?

Those hex numbers are a little on the large side for unsigned char..... lol

A byte will recieve 2 hex digits at most, and a 32-bit integer
(4 bytes), 8 of them. Anyway, the bytes will look the same. In fact, here's an example (sorta):

Code:

char * new_imbedded(int size){
 int si = sizeof(int);
 char * buffer = new char[size + si];
  if(buffer == 0)
   return NULL;
 memcpy( buffer, &size, si );
 return buffer+si; 
}

int imbed_length(char * s){
 int size; 
 int si = sizeof(int);
 s -= si;
 memcpy(&size, s, si);
 return size;
}


int main(){

 char * string = new_imbedded(256);
 cout << imbed_length(string) << endl;
 cin.get();
 delete [] string;

 return 0;
};

Point is, a byte is a byte is a byte...( usually, at least )

Code:

void delete_imbedded(char * s){
 s-=sizeof(int);
 delete [] s;
}

The guilt was driving me crazy.

Those hex numbers are a little on the large side for unsigned char..... lol

oops, I was thinking about binary, not hex...

Heh, sorry sebastiani, you lost me except on the "a byte is a byte" Would you mind re-explaining with bits instead of bytes? lol I mean, supposing the 0x10101010 etc. were binary numbers like I originally intended instead of hex?

In memory, a 4 chars might look like:

[0010111][01011000][0010111][01011000] <--4 chars

If you were to copy these 32 bits (4 * 8 bits = 32 bits) into an integer, there would be no difference at all in the bit configuration.

[001011101011000001011101011000] <-- 1 int

The example I gave earlier is just a trick for storing the size of the array of chars by copying the integer into the first four bytes of the string. Then we return the string but past this stored integer so the user can use it as a normal string. Whenever you need the actual size of the array somewhere in the program, (which could very well differ from it's strlen()), we simply read it into a special function that walks four bytes backwards into the string, reads the size and returns it. Finally, to delete it, we again walk backwards and delete it from the actual first cell (otherwise, delete[] wouldn't find the sting in it's table when we try to delete it!).

Ok, thanks. That's pretty much what I figured, but I wasn't sure.

As for the rest of the stuff, that's pretty cool I'll store it in an empty string somewhere in my empty brain

Hey, just so everyone knows, I originally posted this thread because I am trying to figure out some DirectX thing. This is the code:

Code:

dw = *(DWORD *) ddsd.lpSurface;                 // Get DWORD
if (ddsd.ddpfPixelFormat.dwRGBBitCount < 32)
    dw &= (1 << ddsd.ddpfPixelFormat.dwRGBBitCount) - 1;  // Mask it to bpp

dw is supposed to be assigned the value of the first pixel (i.e. top left-hand corner) on a DirectDraw surface. The part that's confusing me is the "mask it to bpp" part. According to my logic, this is what happens:

(1 << ddsd.(...)) - 1 in binary is just (the number of bits) 1's.
By doing dw &= this value, it gets rid of the left-most bits in dw, leaving only the number of bits that are supposed to make up the colour.

But then, if the bits work as Sebastiani said, wouldn't it get the wrong colour? (i.e. the colour should start with the first byte, but you're cutting off the first byte or 2 or 3 if it's not 32 bits)

Code:

    dw &= (1 << ddsd.ddpfPixelFormat.dwRGBBitCount) - 1;  // Mask it to bpp

It looks like you'd be cutting off the most significant bits. If dwRGBBitCount is 8, you'd be left with the 8 least significant bits. If dwRGBBitCount is 16, you'd be left with the 16 least significant bits. Or it dwRGBBitCount is 31, you'd be left with all bits except for the msb.

Tricky code snippet. At first I thought it was masking off all bits except one.

It looks like you'd be cutting off the most significant bits.

?? But aren't the most significant bits the ones you want?

>?? But aren't the most significant bits the ones you want?

Well, as you said, the colour should start at the first byte. Now for a DWORD of 4 bytes, the first byte is the least significant bits in the DWORD. Usually when something prints its msb to lsb (left to right). So after masking, some of the bits on the left are discarded or zeroed).

It's probably more a matter of interpretation than anything.
Here's some code to show which bits are left for various values of dwRGBBitCount.

Code:

#include <cstdio>
#include <iostream>
#include <iomanip>
#include <windows>

using namespace std;

int main(void)
{
   DWORD dwRGBBitCount;
   DWORD dw;

   for (dwRGBBitCount=1; dwRGBBitCount<32; dwRGBBitCount++)
   {
      dw = 0xffffffff;
      dw &= (1 << dwRGBBitCount) - 1;
      printf("%ld %08X\n",dwRGBBitCount,dw);
      if (dwRGBBitCount%16 == 0)
      {
         printf("Press <Enter> to continue ...");
         cin.get();
      }
   }

   return 0;
}

Thanks a lot, swoopy. I'll take a look, see if I can figure out what everyone's telling me

***EDIT***
Ok, I think I've figured it out, through some swoopy-inspired experiments: array element 0 becomes dw's 1st byte, which is on the right hand side So then the 4th byte is on the left hand side, which is being &ded off. Right?

Hunter2, yes you are correct.

Alright thanks, I had some idea about memory-storing-backwardness when I posted this thread, but I wasn't sure exactly what was backwards