Does setting one pointer to an object to nil affect the object or other pointers to it?

212 views Asked by At

Although I know the main difference between Deep Copy and Shallow Copy but what I want to ask here is something practical.

I have

NSArray *firstArray = [NSArray arrayWithObjects:@"first", @"second",@"third",  nil];
NSArray *secondArray    = firstArray;
secondArray             = nil;

NSLog(@"First Array : %@",firstArray);
NSLog(@"Secon Array : %@",secondArray);

Both the firstArray and secondArray has the same reference as seen by putting break point.

Now my question is this, if both have same REFERENCE then why the firstArray does not change if the secondArray is changed.

I am really confused here... Can any one please make me clear.

Thanks in anticipation.

1

There are 1 answers

11
Tony Delroy On BEST ANSWER

I need to use ASCII art to explain this better...

firstArray
           \
            \
             NSArray - the actual data
            /
           /
secondArray

firstArray and secondArray are just pointers, holding the same numerical (virtual) memory address where the NSArray data is stored. If one of the pointers is set to point to nil, or to some other data for that matter, it won't trigger any change in the NSArray nor the other pointer.

Note especially that while firstArray and secondArray both held the same value initially, they are distinct variables at different memory addresses. You can see that if you print:

NSLog(@"First Array : %@",&firstArray);
NSLog(@"Secon Array : %@",&secondArray);

I think you were mistaking the address they pointed to (the NSArray data's address) for their address, and then concluding they were different names for the same variable. They're not! Each has different memory.

You might want to read up on pointers: What does "dereferencing" a pointer mean?

pointers and references

A pointer variable is much like an integer variable - it takes a few bytes of memory (regardless of the size of the objects at which it may be pointed) and stores a number. That number can be used to record the (virtual) memory address (how many bytes from the 0 origin of (virtual) memory) at which a particular object of the pointed-to type may be found. So, it's a bit like having a piece of paper on which we can write the address of a house. Now, the pointer is NOT the house (data-object), and you can erase the original address and write the address of some other house anytime you like, and you can use that address to find the house. This is what happened in this question... you effectively had two "pieces of paper" on which you'd "written" the address of your "house", then erased one of them, and expected a dramatic affect such as the other piece of paper being erased and/or the house/object being destroyed. Pointers don't work like that.

Some languages have a distinct mechanism - which has been called "references", "aliases", "links" and many other things in various languages' terminology - that works like an additional name or alias for an object. Anything you "do" to one of these things is transparently done to that object instead. Returning to our house analogy: this is like having different names for your house - instead of using the street address, you may call it "home", or "my castle", and if you give the instruction "burn home" your house will really burn. With a pointer to your home - saying "burn pointer-to-home" just burns the piece of paper unless you go to a little extra effort to "dereference" the pointer and operate on the house.

When they need to be passed around the program at run-time, they reference/aliases/things... are typically implemented like pointers - effectively variables that store the address of the data object. But, regardless of whether they've been passed around at run-time or only existed transiently in the compiler's internal records, they operate as described above.

So, to people from a background where "reference" is the technical term used to describe these reference/alias/whatever things, it's "wrong" to hear people say pointers are references... our reaction is "no they're not - you'll burn the paper instead of the house if you think like that". But, there are whole communities of programmers for whom "reference" is another term for "pointer", and these other things might be known as "aliases" or "links" or "pseudonyms" or goodness knows what, or they might just not exist in that language/community (e.g. for C programmers).

All our discussion in comments is just about this potential confusion.

The important this is that you understand that operating on a pointer affects the numeric address in memory that pointer stores, and not the pointed-to object unless you dereference that pointer, and not other pointers to that object (unless they're all "smart pointers" with some deliberately orchestrated synchronisation).

I suggest you read the above until you can't get any more out of it, then re-read What does "dereferencing" a pointer mean? then reread this etc. until you're happy you've grasped it all.

Your current understanding

In comments below, you say:

Up to my understanding, Pointer is a variable that can contain a memory address in it and memory address is always takes as in sense of reference to a value.

The memory address in the pointer can reference/point-at a legitimate object/value, or it may be uninitialised or garbage, just as an integer variable may have a useful number in it or be uninitialised (not yet set), or hold some left-over value after earlier processing that you're no longer interested in.

Let me clear my point here, A Pointer has a memory address , at that memory address there will be some value.

That's ambiguous but correct however you mean it. The ambiguity: the pointer has a memory address in the sense of the memory where the pointer itself is stored. In that sense, every variable has a memory address. But, pointers also have a memory address in the sense of the memory address of the pointed-to data. (This is explained in my other answer linked above.)

So if some one has to get that value, there must be a reference to reach there and that reference is the property of that Point that is containing it.

Well, I think by value you mean the poined-to value: you must have a "memory address" to reach there (whether you want to call that address a reference is discussed above), and that address is stored in the pointer, so you could consider it a "property" of the pointer if you use "property" in the sense used by some languages. So yes! :-) I think your understanding's probably correct, but your terminology is still a little imprecise and ambiguous.