# cs240 data structures

## Recommended Posts

i'm taking a data structures (c++) class and today my prof put the code (below) on the board, and it made me jump in my seat. int a, b; a = 10, b = 6; int *aPtr = &a, *bPtr = &b; // So far so good... aPtr = bPtr Okay this is where everything derailed. He explained to us that once we make the pointer assignment (thus both pointers now point to the same place in memory), that whenever we change bPtr in the future (post-assignment) that aPtr will be automatically changed to match bPtr. So, in other words, he's saying that once a c++ pointer assignment occurs, those pointers are tied to the same memory object for the rest of their lives/scope. PLEASE tell me he's been doing too much research lately, and he's forgetting that this is c++ and not a Java-based DS class he's teaching. I know in Java objects are constructed as references, ergo when you assign them to each other you're just getting two ways to access the same memory unit. Because my understanding was that c++ pointers could be arbitrarily reassigned multiple (infinite) times throughout the program, such as: aPtr = bPtr; aPtr = &someVar; bPtr = &anotherVar; // now they point to 2 totally different vars -- they're not "married" // to each other for the rest of their scope please deliver me from evil....

##### Share on other sites
I think the point he was getting at was not that changing the second pointer will also change the first, but changing the value pointed-to by the second pointer will change the value pointed-to by the first.

aPtr = bPtr;*bPtr = 5; // *aPtr will now also equal 5

That's the only way to interpret what you're saying and still have it make sense. You're right, though; pointers can change whatever they're pointing to whenever they want. Unlike references, they aren't tied to a specific object. Be careful with this when you deal with dynamic memory allocation, though.

##### Share on other sites
Just a note - references can change too:

	int a = 10;	int b = 20;	int &refA = a;	int &refB = b;	refA = b;	refB = a;

They just always have to point to SOMETHING. Of course, you can break that rule by making them point to something that doesn't exist:

	int &refA = *(int*)0;

which sucks.

I agree with Rainault and what he thought your teacher was getting at.

- S

##### Share on other sites
Quote:
 Original post by SphetThey just always have to point to SOMETHING. Of course, you can break that rule by making them point to something that doesn't exist: int &refA = *(int*)0;

Wait, does that not raise an access violation? O_o

EDIT: I guess not, as long as you don't attempt to do stuff with it. Weird.

##### Share on other sites
Quote:
 Original post by SphetJust a note - references can change too: int a = 10; int b = 20; int &refA = a; int &refB = b; refA = b; refB = a;They just always have to point to SOMETHING. Of course, you can break that rule by making them point to something that doesn't exist: int &refA = *(int*)0;which sucks.I agree with Rainault and what he thought your teacher was getting at.- S

Dereferencing a NULL pointer is undefined, as is any code that follows it.

Also, you are not "pointing" refA at 'b' and refB at 'a', you are assigning 'a' through refA to be the value stored in 'b'. Next lines stores the current value of 'a' in 'b' via refB.

So you cannot change what the reference "points" at ( you cannot reseat a reference ). There is no way to syntactially tell the compiler that you want to point the reference elsewhere anyway, all operations on the reference are acted out on the referee...

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
628362
• Total Posts
2982266

• 10
• 9
• 13
• 24
• 11