I'll get It know why I don't have to use sizeof(BYTE) *image[0] is giving me the size of the struct.
But what is this line doing : rptr[k] = aptr + k*ncols; I thought it wat creating positions to use
like array[k][j] and then it wat creating the J position
Last edited by lamko; 09-01-2011 at 04:43 PM.
It's setting rptr[k] to point to an address that is k*ncols structs away, or k*ncols*sizeof(RGBTRIPLE) bytes away, from aptr. That's because C automatically does the sizeof(thing pointed to) part for you, so you get to deal with a more logical unit like structs instead of bytes.Originally Posted by lamko
This also helps when sizeof( RGBTRIPLE ) is not the same as the sum of its members. Structures are often padded, so while its members may only be 3 bytes in total, the structure might actually use 4 bytes of memory.
Quzah.
Hope is the first step on the road to disappointment.
Fine, that I'll understand, but now I want to find the specific struc[1][2] in memory. Any tips on that ?
You mean like doing: foo[ 1 ][ 2 ]?
Quzah.
Hope is the first step on the road to disappointment.
Thx for the info quzah, the padding problem for writing to file I used : __attribute__((__packed__))
edit :
Jup, foo[1][2]
With this code : rptr[k] = aptr + (k * ncols); I'll get these values :
rptr adres = 0x602090 the value there stored is aptr[0] adres = 0x602010
the other pointers are aptr[1]0x602028, aptr[2]0x602040, aptr[3]0x602058, aptr[4]0x602070
So always 18 hex difference thats 24 bits and thats 3 bytes. So puzzle solved, a contiguous block of memory!
No, puzzle NOT solved. You never get addresses of bits, you get it of bytes. Those addresses are 0x18 hex bytes apart, which is 24 bytes in decimal. Why are they 24 bytes apart is the question. The answer is this:
ncols is 8, and sizeof(RGBTRIPLE), which C puts in there automatically, is 3, thus 24 bytes. Multiply that by k each time through your loop (0, 1, 2, 3, 4), and you get offsets of 0, 24, 48, 72 and 96 bytes from aptr.
You just did... struc[1][2] will work just fine... for members struc[1][2].red ... and so on. There's no reason to wast computational time calculating pointers to all these things when the language itself already maps the memory for you. In my experience using the designed in array indexing is easier and often faster than the pointer method... and for a certainty it's more accurate.
(By way of agreeing with Quzah)
Your right anduril462 was the ncols of 8 totally forgotten. CommonTater I didn't used the computer to calculate it, I just viewed the memory adresses of my computer to see if the compiler was doing what I thought it should do. Just like the picture in my opening post.
Thx guys for the help.
