PDA

View Full Version : I think I finally get pointers, 1 question




larswik
Sep 4, 2010, 02:57 AM
It all clicked tonight, thanks Lee and chown33 for the pointers on pointers... I do have one question about this code which functions fine.

#import <Foundation/Foundation.h>

int main (int argc, const char * argv[]) {
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

int num;
int *point;

num = 25;
point = &num;

NSLog(@"point value is %i, and the address is %i", *point, point);
[pool drain];
return 0;
}

In my NSLog statement I end with '*point, point', the first number 25 is of course the value and the second number I was trying to print the address of value NUM. This is the statment that it returned after exicuting.

2010-09-03 22:04:23.992 pointer_test1[16911:10b] point value is 25, and the address is -1073744172

Is it safe to say that that is the address in memory where the variable NUN is allocated? (I hope I got my syntax right).

-Lars



subsonix
Sep 4, 2010, 03:06 AM
You are using the %i format specifier which is for signed integers. Anything larger than 2^31 will overflow, that is why you see a negative number.

For a memory address use the %p format specifier. (Not for the value of num where you dereference point, but for point by itself).

lee1210
Sep 4, 2010, 08:25 AM
http://forums.macrumors.com/showpost.php?p=10989508&postcount=12
I already told you that! =)

-Lee

larswik
Sep 4, 2010, 12:20 PM
Thanks. Lee I did get in your post before. I thought since an address was a number I could also dispay it with %i. I guess for the most part you never need to now the number, the computer takes care of that for you.

Thanks.

lee1210
Sep 4, 2010, 02:11 PM
Thanks. Lee I did get in your post before. I thought since an address was a number I could also dispay it with %i. I guess for the most part you never need to now the number, the computer takes care of that for you.

Thanks.

It is a number. Everything is a binary number. It's all about the byte-width of the type and the interpretation. %c will display that number as a single byte, as a character. %s treats the value as a pointer, then prints each byte starting at the address stored as a character until a null is found. %p will display the actual pointer value (byte width is platform-dependent), not what's stored there.

I have only used %p for debugging. A user never cares about where in memory something is this run of the program.

-Lee

larswik
Sep 4, 2010, 02:42 PM
Gotcha. I have learned about pointers and have a good understanding. I think as I learn Obj C my goal is to have a working knowledge of the elements. It is hard to use pointers in the learning process. NSLog statements are simple you can see on screen what is happening. Pointers deal with behind the scene operations and is at first not obvious what is going on.

My goal now is to double back in the book and learn the things I skipped over because I didn't understand.

Thanks Lee!

chown33
Sep 4, 2010, 02:44 PM
... %c will display that number as a single byte, as a character. %s treats the value as a pointer, then prints each byte starting at the address stored as a character until a null is found. %p will display the actual pointer value (byte width is platform-dependent), not what's stored there.

Also remember that %i treats the value as a 32-bit number, but a pointer in the x86_64 arch is 64-bits.

willieva
Sep 4, 2010, 02:49 PM
Integers are currently 32 bits. This means an int can have a maximum value of 2147483647. Add one to this and the computer will think it's now a negative number.

Pointers have a 64bit unsigned value. That means they can be as large as 2^64. Try to put that into a 32 bit value and you will not get the answer you're looking for.

The computer definitely does not take care of these sorts of things for you. If you're luck you'll get a compiler warning, then the program will happily chug along doing exactly what it was asked to do. And you'll have no idea why things aren't working correctly.

Understanding how computers store numbers is even more basic than pointers.

lee1210
Sep 4, 2010, 03:11 PM
Integers are currently 32 bits. This means an int can have a maximum value of 2147483647. Add one to this and the computer will think it's now a negative number.

Pointers have a 64bit unsigned value. That means they can be as large as 2^64. Try to put that into a 32 bit value and you will not get the answer you're looking for.

The computer definitely does not take care of these sorts of things for you. If you're luck you'll get a compiler warning, then the program will happily chug along doing exactly what it was asked to do. And you'll have no idea why things aren't working correctly.

Understanding how computers store numbers is even more basic than pointers.

Careful IRT generalizations. Pointers are the size of a pointer. How big that is doesn't matter beyond avoiding any assumption about its width compared to other types. Same goes for ints. They are int-sized. INT_MAX will tell you what the max is.

-Lee

willieva
Sep 4, 2010, 04:16 PM
Careful IRT generalizations. Pointers are the size of a pointer. How big that is doesn't matter beyond avoiding any assumption about its width compared to other types. Same goes for ints. They are int-sized. INT_MAX will tell you what the max is.

-Lee

It all depends on what kind of programming you are doing. Generally you are correct, a person shouldn't assume the size of a variable. Assuming a variable has a certain size leads to non-portable code. If you do a lot of work with data where the actual bit patterns matter then knowing the size of variables is essential. Most people probably don't even know what endian their architecture is, but this sort of thing can be critical. Doing mathematical programming and not knowing about the exponent and mantissa will lead to serious errors with precision.

Even programming in java you need to sometimes add an L at the end of a number. Understanding how computers store numbers is important. Had the OP known how variables are stored by a computer, getting a negative number for a pointer address would have stood out as being fundamentally wrong.

lee1210
Sep 4, 2010, 04:32 PM
It all depends on what kind of programming you are doing. Generally you are correct, a person shouldn't assume the size of a variable. Assuming a variable has a certain size leads to non-portable code. If you do a lot of work with data where the actual bit patterns matter then knowing the size of variables is essential. Most people probably don't even know what endian their architecture is, but this sort of thing can be critical. Doing mathematical programming and not knowing about the exponent and mantissa will lead to serious errors with precision.

Even programming in java you need to sometimes add an L at the end of a number. Understanding how computers store numbers is important. Had the OP known how variables are stored by a computer, getting a negative number for a pointer address would have stood out as being fundamentally wrong.

I don't think we disagree on any point. If using a C-based language, float.h constants should be used to determine the datatype you use by way of #define if you know the precision you require. Not sure about java, but I'm guessing you can do something similar.

-Lee