🔒 Locked

Pointers

Started by koopertrooper Nov 19, 2009 at 4:00 PM 10 replies 1.3k views

Original Post

Nov 19, 2009 at 4:00 PM

Hello I got a question about pointers. I got this program: #include using namespace std; int main() { int MegaNumber; int* p; MegaNumber = 2000; p = &MegaNumber int valueofp; valueofp = *p; cout << valueofp << '\n'; p = p++; cout << *p; return 0; } The returns the following output: 2000 -858993460 I am confused to what -858993460 means? Is this a memory address?

BCullis

Nov 19, 2009 at 4:10 PM

p is a variable that holds a memory address (in this specific case, the memory address of an integer). *p dereferences that address, returning the contents of that memory location. When p is incremented ( p = p++; ), you point to the next highest memory address, which can be busy holding...well, anything.

One of the many excitingly dangerous properties of pointers.

nhatkthanh

Nov 19, 2009 at 4:30 PM

are you trying to print out the address of p? If so then use cout << p

lmelior

Nov 19, 2009 at 5:06 PM

Did you know that in this line:

p = p++;

You are trying to create a second temporary pointer equal to p, setting p equal to the copy, and then incrementing p? Something like that, anyway. I'm sure the compiler optimizes it away, but you should know that when you want to increment a variable you only need to do p++ or ++p (no need for the "p =" part).

DevFred

Nov 19, 2009 at 5:10 PM

Quote:
Original post by lmelior
p = p++;

Isn't this undefined behavior? Modifying p twice without a sequence point and such?

BLiTZWiNG

Nov 19, 2009 at 5:29 PM

Quote:
Original post by DevFred
Quote:
Original post by lmelior
p = p++;
Isn't this undefined behavior? Modifying p twice without a sequence point and such?

I'm most certainly no expert, but if you did ask me, wouldn't it just generate (unoptimised)

mov p,p;
inc p;

I'd think the compiler would see it, call you a doofus (internally) and then just output inc p.

jpetrie

Nov 19, 2009 at 5:31 PM

Quote:

Isn't this undefined behavior? Modifying p twice without a sequence point and such?

Yes, it's undefined behavior.

Quote:

The returns the following output:
2000
-858993460
I am confused to what -858993460 means? Is this a memory address?

p is a pointer. Valid values for this pointer are the address of MegaNumber and one-beyond the address of MegaNumber (which you can set p to by doing p++ or ++p, which is what you should have done instead of p = p++). However, while one-beyond the address of MegaNumber is a valid value for p, dereferencing one-beyond the address of MegaNumber is not a valid operation for p at that time, and yields undefined behavior. In this case the undefined behavior has manifested itself by producing a seemingly random value.

In all likelyhood, that value is just some garbage that happened to be resident in memory at that address.

Metsan

Nov 19, 2009 at 5:36 PM

Quote:
Original post by DevFred
Quote:
Original post by lmelior
p = p++;
Isn't this undefined behavior? Modifying p twice without a sequence point and such?

Yes, it's undefined behaviour; the assignment operator does not introduce a sequence point.

koopertrooper

Nov 19, 2009 at 10:59 PM

Thanks for your replies. Yeah I was kind of being lazy! However judging I never knew that programmers had to be so strict I will watch out in future. Not in maths where it just makes it a bit longer to solve the problem although if its a test you can loose marks by running out of time if you do it too often. :D

Quote:
Original post by nhatkthanh
are you trying to print out the address of p? If so then use cout << &p

Just out of curiosity. If I do change to &p like in this version:

int main(){               int MegaNumber;	int* p;	MegaNumber = 2000;	p = &MegaNumber	int valueofp;	valueofp = *p;	cout << &p << '\n';	p++;		cout << &p }

The output I get is this:

002DFBF0002DFBF0

Which it seems the memory address is identical in both cases whether it refers to the MegaNumber memory address or the one thats garbage. So does this mean that variable p is storing a copy of what is at that memory address it's pointing to at its own memory address or is it where information containing the memory address of where the variable it is referring to is? Surely it's the latter.

fastcall22

Nov 20, 2009 at 12:17 AM

Quote:

So does this mean that variable p is storing a copy of what is at that memory address it's pointing to at its own memory address or is it where information containing the memory address of where the variable it is referring to is?

I'm not exactly sure what you mean here; hopefully this should clear things up:

int MegaNumber = 1000;int *p = &MegaNumbercout << &p << '\n'; // Prints the address of the pointer variable (int **)cout << p << '\n'; // Prints the address of what the pointer points to (int *)cout << *p << '\n'; // Prints the value the pointer points to (int)p ++;cout << &p << '\n'; // The location of the variable "p" has not changedcout << p << '\n'; // But, what "p" points to has changedcout << *p << '\n';

[Edited by - _fastcall on November 20, 2009 12:17:14 AM]

Aardvajk

Nov 20, 2009 at 12:52 AM

Since you expect the values to differ, I assume you are trying to print the address that p points to, not the address of p.

You can get a std::ostream to do this by casting the pointer to void*, which has a different overload for <<:

#include <iostream>int main(){    int i=23;    int *p=&i    std::cout << static_cast<void*>(p) << std::endl;    p++;    std::cout << static_cast<void*>(p) << std::endl;}

On my machine, this produces:

0x22ff440x22ff48

The difference between the two would reflect the size of an int using gcc 32-bit compiler.

[EDIT - actually, it seems for non char* (in all its various const combinations) pointer types, the cast to void* is not necessary.]

DevFred

Nov 20, 2009 at 1:48 AM

Quote:
Original post by Aardvajk
[EDIT - actually, it seems for non char* (in all its various const combinations) pointer types, the cast to void* is not necessary.]

Correct. operator<< is specifically overloaded for char*. Otherwise, std::cout << "hello\n" would not do what one expects :)

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.