Pointers and Garbage Collection – Understanding Their Relationship

garbage-collectionpointers

I am a little confused on both pointers and reference. From my understanding pointers are addresses in memory. If I pass a variable using pointers and reference to a function, any manipulations of the variable in the function will change the original variable.

I read online that passing by reference is not encouraged because it can get messy code easily. I also read here (https://stackoverflow.com/questions/7058339/c-when-to-use-references-vs-pointers), that we should avoid pointers if we can.

My question is when should pointers and reference be used? I know pointers are used in Xcode for strong references and reference counting. Since, higher level languages like c# have garbage collector, does that mean we shouldn't ever use pointers and reference in them?

Best Answer

I am a little confused on both pointers and reference. From my understanding pointers are addresses in memory.

In general, they are both addresses in memory. Usually one speaks of pointers if arithmetic can be done on them and of references if not, but there are some language-specific variations.

If I pass a variable using pointers and reference to a function, any manipulations of the variable in the function will change the original variable.

Yes.

But there are three reasons for passing something by reference:

  1. To avoid copying large amount of data to the stack.
  2. To modify the original variable.
  3. To support polymorphism, as the generated code does not know in advance how large the object will be and how to properly copy it.

Code using the second option is always more difficult to read than code using return values and if it is not used consistently, it is a sure way to create real mess. To distinguish this case from the other two C++ has the const modifier. Unfortunately Java and C# don't (and their authors don't seem to understand why it is useful; might have something to do with the fact that many people sell const in C/C++ as optimization tool which it certainly isn't).

I read online that passing by reference is not encouraged because it can get messy code easily.

High level languages hold everything by reference, because of the reason 3 above. They may pass the reference by value (just like passing pointer in C; the function can't change where the pointer points, but it can change content of the pointed object) or by reference (that is pointer-to-pointer; the function can make the variable point to different object), but it is always a reference to the actual object.

Java does that except for primitive numeric types and C# does it for everything that is class.

But passing by reference for the reason 2 above is indeed discouraged. One simply does not normally expect function to modify it's arguments, so better not do it.

I also read here (https://stackoverflow.com/questions/7058339/c-when-to-use-references-vs-pointers), that we should avoid pointers if we can.

That is C++-specific. References can't be set to nullptr (0 in older C++) so you don't have to check and references can't be deleted, so you don't have to think whether you should.

My question is when should pointers and reference be used?

Wherever they have to be.

I know pointers are used in Xcode for strong references and reference counting. Since, higher level languages like c# have garbage collector, does that mean we shouldn't ever use pointers and reference in them?

Managed languages (C#, Java, ...) don't have pointers at all. Pointers allow access to raw memory and that would interfere with the managed runtime. So they don't have them (C# does, in the special, "unsave", extension, to allow interfacing with plain old C libraries).

But references can't be not used in them. Everything is a reference. Because allocated memory can only be handled by pointer/reference. And because of polymorphism. So all variables of object types are references in Java and C# and all variables are references in anything dynamically typed like smalltalk, perl, python, ruby, javascript etc.