My question regards pp_ptr<(my_array_size + val_array)
my_array_size is an int and val_array = hex, yet they are added together. Of course I suspect something else is going on here since you cannot add the two (?) and the loop works great.
Whats going on with the addition with a decimal and hex?
A value is a value. 0x2A is what is known as a hex literal (a "literal" being a token, and a token being an indivisible syntactical element of the language). The compiler generated for it an object of the same type and value as the objects it generates for 052 and 42, correspondingly the equivalent octal and decimal literals.
The expression (0x2A == 42 && typeid(0x2A) == typeid(42)) is invariably true, in any implementation.
val_array is the address of the first element of the array
val_array + my_array_size describes the outer boundary:(my_array_size + val_array)
as long as this is not exceeded the loop stays within the address boundary of the array
my question is now: to determine the outermost boundary address of the matrix we will have to add n elements to the val_array address. So if we have a 5 int array, it might look something like this:
But how does the compiler treat (my_array_size + val_array)? The output is a range of addresses that are somehow derived from what would seem should be 2 values added together from (my_array_size + val_array)
More directly: how do these two arguments determine the outer boundary value of the array?
When you declare an array of something, the compiler knows how big one element is, and it uses this info to do pointer arithmetic in relation to the array subscript, or any incrementing of pointers etc. So if one had an array of 10 items, each occupying 128 bytes say, the address of the last element would be the start address + (9 * 128) because array subscripts start at 0. You can test this by writing some code which has an array of struct, and cout the pointers themselves. The compiler will probably align the memory to 32 or 64 bit boundaries, so be aware of that when you decide on what is in your struct .
For your first question: decimal, octal and hex numbers are still ints, they are just expressed differently. Edit: Which is the same as what helios said. The complier is going to convert them to binary whatever they are. You can test this with code too, the compiler will happily add up decimal, octal and hex numbers.
The name of the array is the start address, in other words the name of the array is replaced by the address of the array. It is interesting you have coded it like this:
pp_ptr<(my_array_size + val_array)
rather than:
pp_ptr<(val_array + my_array_size)
There is no difference to the compiler, but the latter is more intuitive IMO.
Going back to what I said before: The address of the n'th element of the array is start address + (n * size(1 element))
TheIdeasMan wrote:
You can test this by writing some code which has an array of struct, and cout the pointers themselves. The compiler will probably align the memory to 32 or 64 bit boundaries, so be aware of that when you decide on what is in your struct .
So make a struct which is 64 bit in size (2 int's say), then make an array of 10 of these. Use a for loop to print out the addresses of each element. Then verify that the addresses increment by 8 bytes each time.