We Keep Coding

How are BigInteger passed in functions

Are BigIntegers in C# passed by value or by reference? I am having a code in which I need to pass them by value and I think they are passed as reference personally, as the value is changed after some calls in initial calling function, not sure though if it is the case actually.
Please help :)

Technically speaking, all objects in C# (and Java as well) are passed by value (by default).
For reference types, this value happens to be a reference (pointer). That's why changes inside the method affects the actual object.
For value types, this value is the actual value the variable holds. That's why changes inside the method doesn't affect the actual object.
BigInteger is not special in anyway, it's a struct (which is a value type).
If you want to pass an object by reference, you can use ref keyword.
See also:
Passing Reference-Type Parameters (C# Programming Guide)
Passing Value-Type Parameters (C# Programming Guide)
You may also want to give a look at the answers for this question.

BigInteger is a struct, so it is a value type and it is passed by value by default:
Because a struct is a value type, when you pass a struct by value to a method, the method receives and operates on a copy of the struct argument. The method has no access to the original struct in the calling method and therefore can't change it in any way. The method can change only the copy.
Passing Value-Type Parameters (C# Programming Guide)
A value-type variable contains its data directly as opposed to a reference-type variable, which contains a reference to its data. Passing a value-type variable to a method by value means passing a copy of the variable to the method. Any changes to the parameter that take place inside the method have no effect on the original data stored in the argument variable. If you want the called method to change the value of the argument, you must pass it by reference, using the ref or out keyword. You may also use the in keyword to pass a value parameter by reference to avoid the copy while guaranteeing that the value will not be changed. For simplicity, the following examples use ref.
If you want to pass such type by reference, you can use the ref keyword.
Passing Reference-Type Parameters (C# Programming Guide)
A variable of a reference type does not contain its data directly; it contains a reference to its data. When you pass a reference-type parameter by value, it is possible to change the data belonging to the referenced object, such as the value of a class member. However, you cannot change the value of the reference itself; for example, you cannot use the same reference to allocate memory for a new object and have it persist outside the method. To do that, pass the parameter using the ref or out keyword. For simplicity, the following examples use ref.
It will therefore be only the memory pointer (4 or 8 bytes on x32 or x64 systems) which is pushed into the stack before the call of a method (like an instance of a class) instead of the entire structure content (the copy of all members, for example 8x4 bytes if the struct has 8 integers, at least).
Pass c# struct by reference
Passing a struct by Reference
Pass reference by reference vs pass reference by value - C#
Passing a Reference vs. Value (Pluralsight)
Understanding C# Pass by Reference and Pass by Value (Udemy)
Passing Arguments By Value and By Reference (C# 6 for Programmers, 6th Edition)

Why some C# library functions don't follow the "ref" parameter passing convention

There are many examples, let's take array copy method as an example. The signature of the Array.Copy is method is as below
public static void Copy (Array sourceArray, long sourceIndex, Array destinationArray, long destinationIndex, long length);
Judging only from signature, one can not tell that the sourceArray will not be changed while the destinationArray will be altered, even if it is some thing as simple as an array of Int. The guarantee coming from the keyword "ref" for programmers have lost here.
It seems to me that the the destinationArray parameter should better be marked as "ref Array". If it had been done this way, the syntax would be more consistent with the usage of the keyword "ref", indicating that the passed in object might be modified by the callee and the change is visible for the caller. The only benefit I can think of concerning mitting the keyword "ref", is that saves a few key strokes. or it is just mimicking the C/C++ style without much thinking.
My question is: what are some seasonings behind this design decision?
Update: For the record, I am advocating that an array be of the same value/reference category as its elements, thus making a clear extinction between Fun(array) and Fun(ref array), that is the same guarantee programmers get with Fun(int) and Fun(ref int). Optimization for efficiency can be left to the implementation level.

Array is a reference type. You can pass references by value and the instances they reference will still be the same ones that get modified. The callee is modifying the same instance using its own reference to it and has no reason to change it into a completely different instance entirely (which is where ref would actually come into use).
There isn't any convention that states to use ref when passing reference types — you generally don't need to most of the time, except as mentioned if your method actually intends to change the instance entirely like so:
class Foo { public int Value; }
public static void ReplaceFoo(ref Foo foo)
{
foo = new Foo { Value = 2 };
}
var foo = new Foo { Value = 1 };
Console.WriteLine(foo.Value);
ReplaceFoo(ref foo);
Console.WriteLine(foo.Value);
Judging only from signature, one can not tell that the sourceArray will not be changed while the destinationArray will be altered
Why is this a problem? No one reads APIs only paying attention to method signatures and ignoring parameter names. Signatures are there for the compiler to distinguish overloads. Anyone reading the API for Array.Copy() would understand that sourceArray is going to be unchanged, being where the method is getting the values from, and destinationArray is going to be modified, being the one receiving the values — unless they don't speak English (which is fine, but most APIs are written in English).
The only other scenario I can think of where a reader would be confused is if they didn't have the prior knowledge that arrays are reference types in .NET. But misusing ref in a situation where it's not needed at best and inappropriate at worst doesn't solve that problem.

C# (and .NET) include both reference types and value types.
Normally (absent ref or out keywords), parameters are passed to methods by value. So, if you pass an integer to a function, the value of the integer is passed. If you put a a variable referring to an array in a function call (remembering that all arrays are instances of the reference type System.Array), the value of that variable, i.e., the reference to to the array, is passed to the function.
So, within the function, the code gets to play on that array. When the function returns, that variable (in the scope of the caller) still refers to that same object. However, the function may have mutated that array, so the variable (in the caller scope) may be referring to a changed object.
If you pass a value type by reference (with the ref keyword), the function can change the value of the parameter, and when the function returns, the variable (in the caller scope) will receive the new value.
But, if you use ref (or out) on a parameter of reference type, you are passing a reference by reference. So, for example, you could pass in an array of five integers and the function could assign that parameter and array of ten integers (they are of the same type, but definitely differentobjects). In the caller, when the function returns, the variable associated with that parameter will see what it refers to completely change during the call.
In your example, the caller will instantiate two arrays of the same type and compatible lengths (usually the same length if the source and destination indexes are 0 and the length is sourceArray.Length). The function does not change what object the destination array parameter refers to, it just fills the destination from the source.
In fact, if the destination was by ref, it wouldn't be as flexible. Consider a case where the destination is 30 entries long, and your intention is to fill the middle ten array entries with the source. It just works. It wouldn't with a ref destination parameter (without a lot more work).

The reason for omitting the ref keyword is that in most cases, it won't make any difference to include it, so it's superfluous. However, it does actually make a difference in some cases. An array is a reference type, and that means a value representing that reference gets passed. Normally, updating the passed in value will trigger updates to the original object. BUT if you create a NEW array and assign the passed in parameter to the new item, the reference gets lost - whereas the ref keyword preserves it.

C# callback requires object to be referenced as UInt32? [duplicate]

This question already has answers here:
What is void* in C#? [duplicate]
(7 answers)
Closed 6 years ago.
I need to be able to pass a context object when i register a call back using the following method, which is linked to a C++ DLL file so cant change the method parameters. The callback returns this as one of the arguments when the callback method is executed.
public static void RegisterCallback(UInt32 instance, CALLBACK callbackFunction, UInt32 context)
The last argument is the only one I'm having trouble with. I'm assuming that its meant to be the memory address (or a reference) of the object.
The C++ code has this argument as void*
Any ideas?

This is very common in a C-style api that permits registering a callback. It plays the exact same role as, say, IAsyncResult.AsyncState in managed code for example. The callback gets the value back, it can use it for any purpose it likes. Could be an index in an array of objects for example. Could be a state variable. In the case of C++, it very commonly is the this pointer of the C++ object. Very handy, permits calling an instance function of the C++ object. Anything goes.
Do note that it is pretty unlikely that you need it. First hint that you don't is that you just don't know what to use it for. And that's pretty likely in C# because you already have context. The delegate you use for the callbackFunction argument already captures the this object reference. So any state you need in the callback method can already be provided by fields of the class. Just like C++, minus the extra call.
So don't worry about it, pass 0. Or really, fix the declaration, the parameter should be IntPtr, pass IntPtr.Zero. Probably also what you should do for the instance argument, it quacks like a "handle". A pointer under the hood.
And be careful with the callbackFunction argument, you need to make sure that the garbage collector does not destroy the delegate object. It does not know that the native code is using it. You have to store it in a static variable or call GCHandle.Alloc() so it is always referenced.

Is there a way to constrain anonymous function parameter's scope?

I have a method that takes an anonymous function parameter. This function's parameter is provided by a local variable.
public void DoSomething<T>(Action<T> method) where T : new()
{
T instance = new T();
method.Invoke(instance);
}
I want to prevent creating a closure. Local variable should go out of scope when DoSomething<T> is finished. Is there a way to constrain it at compile time?
Here's the situation I want to avoid:
Foo capturedInstance = null;
DoSomething<Foo>(item => capturedInstance = item);
capturedInstance.Call();

Unfortunately*, that's not possible. You have little to no control over what a method does with its arguments. It would be possible to work around if you weren't using generic types, but you are, so just don't worry about that kind of situation. (I hope you don't have to.)
* Actually, I consider it "fortunately". This isn't C++ we're talking about here.

If T were a struct, it would be possible for code which held a field of type T or an array of type T[] to pass the field or an array element as a ref parameter to an outside method; that method would be able to operate directly and efficiently on that field or array slot without having to make temporary copies of the struct, but once the method returned the type holding the field or array could be confident that outside code could no longer access that slot. Outside could have made a copy of the field or element's contents, of course, but it won't be able to change the original unless or until the type holding the struct again exposes it to outside code.
Unfortunately, if the T is a mutable class, exposing a reference will allow outside code to promiscuously copy and pass around that reference forevermore. For that reason, mutable classes are much worse data holders than mutable structs. If one wants to allow outside code to make use of a class without exposing a direct reference, it's necessary to create a wrapper class and interface. Unfortunately, there's no way of doing this without either using a truly horrible amount of duplicated code, or else using Reflection to generate wrappers at run-time.

I think your code already does what you want.
The delegate representing the lambda item => capturedInstance = item is passed only to DoSomething<Foo>, and that reference is not handed out to anybody else. So, the delegate would go out of scope when the containing method finishes. And so will the local variable that is captured by the lambda expression.
Only if you are passing around a reference to the delegate, you will not get the behavior you want.

What is a Value Class and what is a reference Class in C#?

What is the definition of a value class and reference class in C#?
How does this differ from a value type and reference type?
I ask this question because I read this in the MCTS Self-Paced Training Kit (Exam 70-536). Chapter 1, Lesson 1, Lesson review 4 :
You need to create a simple class or
structure that contains only value
types. You must create the class or
structure so that it runs as
efficiently as possible. You must be
able to pass the class or structure to
a procedure without concern that the
procedure will modify it. Which of the
following should you create?
A reference class
B reference structure
C value class
D value structure
Correct Answer: D
A Incorrect: You could create a
reference class; however, it could be
modified when passed to a procedure.
B Incorrect: You cannot create a
reference structure.
C Incorrect: You could create a value
class; however, structures tend to be
more efficient.
D Correct: Value structures are
typically the most efficient.

You may be thinking of C++/CLI which, unlike C#, allows the user to declare a "value class" or a "ref class."
In C#, any class you declare will implicitly be a reference class - only built-in types, structs, and enums have value semantics.
To read about value class in C++/CLI, look here:
http://www.ddj.com/cpp/184401955
Value classes have very little functionality compared to ref classes, and are useful for "plain old data"; that is, data which has no identity. Since you're copying the data when you assign one to another, the system provides you with a default (and mandatory) copy constructor which simply copies the data over to the other object.
To convert a value class into a reference class (thereby putting it on the garbage-collected heap) you can "box" it.
To decide whether a class you are writing is one or the other, ask yourself whether it has an identity. That usually means that it has some state, or has an identifier or a name, or a notion of its own context (for example a node pointing to nearby nodes).
If it doesn't, it's probably a value class.
In C#, however, value classes are declared as "structs".

See the overview on the subject, but seriously follow the msnd links and read the full Common Type system chapter of it. (You could also have asked in a comment in the first, question)

Value types are passed by value, while reference types are passed by reference.
Edit: value/reference classes
There is no concept of a 'value class' or 'reference class' in C#, so asking for its definition is moot.

Value types store the actual data while reference types store references to the data. Reference types are stored dynamically on the heap while value types are stored on the stack.
Value Types: http://msdn.microsoft.com/en-us/library/s1ax56ch.aspx
Reference Types: http://msdn.microsoft.com/en-us/library/490f96s2.aspx

When you refer to a value type (that is, by using its name), you're talking about the place in memory where the data is. As such, value types can't be null because there's no way for the memory location to say "I don't represent anything." By default, you pass value types by value (that is, the object you pass in to methods doesn't change as a result of the method's execution).
When you use a reference type object, you're actually using a pointer in disguise. The name refers to a memory location, which then references a place in memory where the object actually lives. Hence you can assign null to a reference type, because they have a way of saying "I point to nowhere." Reference types also allow the object to be changed as a result of methods executing, so you can change myReferenceObject's properties by passing it into a method call.

Reference types are passed to methods by reference and value types by value; in the latter case a method receives a copy of the variable and in the former it receives a reference to the original data. If you change your copy, the original does not change. If you change the original data you have a reference to, the data changes everywhere a reference to the data is changed. If a similar program to your C# program was created in C, generally reference types would be like data using pointers and value types would be normal data on the stack.
Numeric types, char, date, enumerations, and structures are all value types. Strings, arrays, delegates and classes (i.e., most things, really) are reference types.

If my understanding is correct, you can accomplish a "value class", or immutable class, through the use of readonly member variables initialized through the constructor. Once created, these cannot be changed.