Click here to Skip to main content
15,879,474 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I have been diving pretty deep into these topics recently and would like confirm with you guys (the C# community) if my assumptions on the following topics are correct. Thus, please correct if any of my bottom assumptions to the following topics are incorrect:

An argument(s) passed by Value: Means to pass either a copy of an actual instance(when the type of the instance is of a Value type) or the memory location of an instance(when the type of the instance is of a Reference type).

An argument(s) passed by Reference: Means to the pass the memory location of a variable storing either an actual instance(when the type of the instance is of a Value type) or the memory location of an instance(when the type of instance is of a Reference type).

A value returned by Value: Means to return either a copy of an actual instance(when the type of the instance is of a Value type) or the memory location of an instance(when the type of the instance is of a Reference type).

A value returned by Reference: Means to return a the memory location of a variable that stores either an actual instance(when the type of the instance is of a Value type) or the memory location of an instance(if its type is of a Referene type).

What I have tried:

I just want to confirm if my assumptions are correct.
Posted
Updated 20-Apr-21 17:31pm
v2

1 solution

Sort of. But ... it's not a "memory location" that is passed or returned - it's a reference, which is different. Calling it a "memory location" implies that it returns a pointer, which it doesn't - a reference is not a pointer, although you can think of it as a "pointer on steroids".
Returning a reference to a value is complicated (and pretty new, it was only added at C# 7.0) because you have to avoid the old C and C++ problem of "dangling pointers", where the pointer you return from a function call is to a local variable which has been deallocated because the function has exited. Microsoft makes a pretty good job of describing it: Ref return values and ref locals (C# Guide) | Microsoft Docs[^]

But returning a reference to a value type is not a case of "returning a pointer" at all: it returns a reference to a boxed value type - i.e. the value is copied into a new object instance which is created on the heap for it, and the reference to that is returned, not a reference to the original value type instance. Boxing and Unboxing - C# Programming Guide | Microsoft Docs[^]
That means that the operation may take some time (if the struct is large, then a lot of copying gets done, as well as the allocation of a large object on the heap).

Quote:
Also while on StackOverFlow I came across this statement that supposably establishes the difference between a reference and a pointer: "A pointer points to a place in memory while a reference points to an object in memory"... Is there any truth to this statement in terms of it tying into what you were trying to explain in your answer???


Don't think about pointers here, they don't help!
A reference is not a pointer - C# has pointers, but they are deliberately disabled by default (and require the "unsafe" keyboard in order to be "turned on") and they require some very careful coding when you do use them, for one important reason: the memory that a reference refers to is not fixed in place.
The Garbage collector can move memory around to free up larger chunks, and this happens behind the scenes so your code isn't even aware that the data you are working with is no longer in the same place - and when it does all the references to that memory automatically refer to the right place.

With pointers, that can't happen, because a pointer refers to a specific location in memory, and if that data is moved, then all the pointers need to be changed simultaneously - including all the ones which are pointing to a character further on in the string for example:
C++
char p1[] = "Hello World!";
char* p2 = p1 + 6;
If you move the data "Hello World!" in memory, then you have to also change p1 and p2 appropriately, and that gets horribly complicated and difficult.

A reference gets around that because (although it uses a pointer internally) what it points to is an object (which also says what type of data it is) and the object can be moved by the GC with impunity.

Basically, don't worry about it - but don't use "points to" in terms of a reference because that implies actual C# pointers, and they aren't the same.
If you really want to kn ow how all this is done behind the scenes, start here: .NET Type Internals - From a Microsoft CLR Perspective[^] - but don't expect it to be "beginner friendly" or even useful in everyday coding! :laugh:
 
Share this answer
 
v2
Comments
Maciej Los 20-Apr-21 8:55am    
5ed!
[no name] 20-Apr-21 23:39pm    
Thanks for the input. Actually by "memory location" or as some say "memory address"(referring to where the variable or instance of Reference type is found in the Heap) I was trying to imply "A reference being passed or returned".

Also while on StackOverFlow I came across this statement that supposably establishes the difference between a reference and a pointer: "A pointer points to a place in memory while a reference points to an object in memory"... Is there any truth to this statement in terms of it tying into what you were trying to explain in your answer???
OriginalGriff 21-Apr-21 2:48am    
Answer updated.
BillWoodruff 21-Apr-21 3:18am    
+5 bulls-eye
[no name] 23-Apr-21 11:17am    
That was very insightful! Thanks for sharing. This greatly helped my understanding on the matter. And hopefully to anyone else.

As a final note question though. You stated "but don't use 'points to' in terms of a reference because that implies actual C# pointers, and they aren't the same."... Than what would be the appropriate phrase or word to use in terms of a reference?

For example: A reference "--------" an object in memory.
Instead of: A reference "points to" an object in memory.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900