Jump to content
  • Advertisement
Sign in to follow this  
hisDudeness

cs240 data structures

This topic is 4399 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement
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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by Sphet
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;

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 this post


Link to post
Share on other sites
Quote:
Original post by Sphet
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


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...

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!