Following is a test class
public class Test
{
public int a;
}
Following are the Extension methods I have created:
public static class Extension
{
public static void Do1(this Test t,int value)
{
t.a = t.a + value;
}
public static Test Do2(this Test t,int value)
{
t.a = t.a + value;
return t
}
}
Code Usage:
Test t = new Test();
t.a = 5;
Both the following calls lead to same result for t.a, which is 10:
t.Do1(5)
t = t.Do2(5)
There are many instances in my code where I need to implement a similar logic, which one is better, one of them is passing reference by value and internally updating it, other is returning the updated reference. Is using one of them safer, if this kind of code ever gets into multi threaded wrapper, provided all the thread safety is taken care of. Normally to update the referenced variable we need a ref or out keyword, which is like pointer to a pointer, instead of a separate pointer to same memory location as in this case, but here in extension methods, I cannot use them. Please let me know if the question needs further clarity
In your example it does not make sense to return the tvariable. t is a reference, so setting t.a updates the object already. There's no need for ref, out or returning t. One reason for returning t would be to allow you to use method chaining.
You only need ref or out if you want to actually change the reference, not the content of the reference.
You are actually misunderstanding sense of ref and out keywords. Those are used, if you want to replace whole referenced object inside your method, for simple property level update they are not needed at all.
In your example, as Test is a class (reference type), there is no actual difference between two methods, but returning initial Test object as in Do2 method is just pointless, as object was already updated. So best of two will be the first implementation:
public static class Extension
{
public static void Do1(this Test t,int value)
{
t.a = t.a + value;
}
}
Going back to Do2 method - as I said before, referenced object value is already updated inside a method, so there is even no point in assigning return value to initial variable:
t.Do2(5)
is the same as
t.Do(5)
Related
If I am passing an object to a method, why should I use the ref keyword? Isn't this the default behaviour anyway?
For example:
class Program
{
static void Main(string[] args)
{
TestRef t = new TestRef();
t.Something = "Foo";
DoSomething(t);
Console.WriteLine(t.Something);
}
static public void DoSomething(TestRef t)
{
t.Something = "Bar";
}
}
public class TestRef
{
public string Something { get; set; }
}
The output is "Bar" which means that the object was passed as a reference.
Pass a ref if you want to change what the object is:
TestRef t = new TestRef();
t.Something = "Foo";
DoSomething(ref t);
void DoSomething(ref TestRef t)
{
t = new TestRef();
t.Something = "Not just a changed t, but a completely different TestRef object";
}
After calling DoSomething, t does not refer to the original new TestRef, but refers to a completely different object.
This may be useful too if you want to change the value of an immutable object, e.g. a string. You cannot change the value of a string once it has been created. But by using a ref, you could create a function that changes the string for another one that has a different value.
It is not a good idea to use ref unless it is needed. Using ref gives the method freedom to change the argument for something else, callers of the method will need to be coded to ensure they handle this possibility.
Also, when the parameter type is an object, then object variables always act as references to the object. This means that when the ref keyword is used you've got a reference to a reference. This allows you to do things as described in the example given above. But, when the parameter type is a primitive value (e.g. int), then if this parameter is assigned to within the method, the value of the argument that was passed in will be changed after the method returns:
int x = 1;
Change(ref x);
Debug.Assert(x == 5);
WillNotChange(x);
Debug.Assert(x == 5); // Note: x doesn't become 10
void Change(ref int x)
{
x = 5;
}
void WillNotChange(int x)
{
x = 10;
}
You need to distinguish between "passing a reference by value", and "passing a parameter/argument by reference".
I've written a reasonably long article on the subject to avoid having to write carefully each time this comes up on newsgroups
In .NET when you pass any parameter to a method, a copy is created. In value types means that any modification you make to the value is at the method scope, and is lost when you exit the method.
When passing a Reference Type, a copy is also made, but it is a copy of a reference, i.e. now you have TWO references in memory to the same object. So, if you use the reference to modify the object, it gets modified. But if you modify the reference itself - we must remember it is a copy - then any changes are also lost upon exiting the method.
As people have said before, an assignment is a modification of the reference, thus is lost:
public void Method1(object obj) {
obj = new Object();
}
public void Method2(object obj) {
obj = _privateObject;
}
The methods above does not modifies the original object.
A little modification of your example
using System;
class Program
{
static void Main(string[] args)
{
TestRef t = new TestRef();
t.Something = "Foo";
DoSomething(t);
Console.WriteLine(t.Something);
}
static public void DoSomething(TestRef t)
{
t = new TestRef();
t.Something = "Bar";
}
}
public class TestRef
{
private string s;
public string Something
{
get {return s;}
set { s = value; }
}
}
Since TestRef is a class (which are reference objects), you can change the contents inside t without passing it as a ref. However, if you pass t as a ref, TestRef can change what the original t refers to. i.e. make it point to a different object.
With ref you can write:
static public void DoSomething(ref TestRef t)
{
t = new TestRef();
}
And t will be changed after the method has completed.
Think of variables (e.g. foo) of reference types (e.g. List<T>) as holding object identifiers of the form "Object #24601". Suppose the statement foo = new List<int> {1,5,7,9}; causes foo to hold "Object #24601" (a list with four items). Then calling foo.Length will ask Object #24601 for its length, and it will respond 4, so foo.Length will equal 4.
If foo is passed to a method without using ref, that method might make changes to Object #24601. As a consequence of such changes, foo.Length might no longer equal 4. The method itself, however, will be unable to change foo, which will continue to hold "Object #24601".
Passing foo as a ref parameter will allow the called method to make changes not just to Object #24601, but also to foo itself. The method might create a new Object #8675309 and store a reference to that in foo. If it does so, foo would no longer hold "Object #24601", but instead "Object #8675309".
In practice, reference-type variables don't hold strings of the form "Object #8675309"; they don't even hold anything that can be meaningfully converted into a number. Even though each reference-type variable will hold some bit pattern, there is no fixed relationship between the bit patterns stored in such variables and the objects they identify. There is no way code could extract information from an object or a reference to it, and later determine whether another reference identified the same object, unless the code either held or knew of a reference that identified the original object.
This is like passing a pointer to a pointer in C. In .NET this will allow you to change what the original T refers to, personally though I think if you are doing that in .NET you have probably got a design issue!
By using the ref keyword with reference types you are effectively passing a reference to the reference. In many ways it's the same as using the out keyword but with the minor difference that there's no guarantee that the method will actually assign anything to the ref'ed parameter.
ref mimics (or behaves) as a global area just for two scopes:
Caller
Callee.
If you're passing a value, however, things are different. You can force a value to be passed by reference. This allows you to pass an integer to a method, for example, and have the method modify the integer on your behalf.
If I am passing an object to a method, why should I use the ref keyword? Isn't this the default behaviour anyway?
For example:
class Program
{
static void Main(string[] args)
{
TestRef t = new TestRef();
t.Something = "Foo";
DoSomething(t);
Console.WriteLine(t.Something);
}
static public void DoSomething(TestRef t)
{
t.Something = "Bar";
}
}
public class TestRef
{
public string Something { get; set; }
}
The output is "Bar" which means that the object was passed as a reference.
Pass a ref if you want to change what the object is:
TestRef t = new TestRef();
t.Something = "Foo";
DoSomething(ref t);
void DoSomething(ref TestRef t)
{
t = new TestRef();
t.Something = "Not just a changed t, but a completely different TestRef object";
}
After calling DoSomething, t does not refer to the original new TestRef, but refers to a completely different object.
This may be useful too if you want to change the value of an immutable object, e.g. a string. You cannot change the value of a string once it has been created. But by using a ref, you could create a function that changes the string for another one that has a different value.
It is not a good idea to use ref unless it is needed. Using ref gives the method freedom to change the argument for something else, callers of the method will need to be coded to ensure they handle this possibility.
Also, when the parameter type is an object, then object variables always act as references to the object. This means that when the ref keyword is used you've got a reference to a reference. This allows you to do things as described in the example given above. But, when the parameter type is a primitive value (e.g. int), then if this parameter is assigned to within the method, the value of the argument that was passed in will be changed after the method returns:
int x = 1;
Change(ref x);
Debug.Assert(x == 5);
WillNotChange(x);
Debug.Assert(x == 5); // Note: x doesn't become 10
void Change(ref int x)
{
x = 5;
}
void WillNotChange(int x)
{
x = 10;
}
You need to distinguish between "passing a reference by value", and "passing a parameter/argument by reference".
I've written a reasonably long article on the subject to avoid having to write carefully each time this comes up on newsgroups
In .NET when you pass any parameter to a method, a copy is created. In value types means that any modification you make to the value is at the method scope, and is lost when you exit the method.
When passing a Reference Type, a copy is also made, but it is a copy of a reference, i.e. now you have TWO references in memory to the same object. So, if you use the reference to modify the object, it gets modified. But if you modify the reference itself - we must remember it is a copy - then any changes are also lost upon exiting the method.
As people have said before, an assignment is a modification of the reference, thus is lost:
public void Method1(object obj) {
obj = new Object();
}
public void Method2(object obj) {
obj = _privateObject;
}
The methods above does not modifies the original object.
A little modification of your example
using System;
class Program
{
static void Main(string[] args)
{
TestRef t = new TestRef();
t.Something = "Foo";
DoSomething(t);
Console.WriteLine(t.Something);
}
static public void DoSomething(TestRef t)
{
t = new TestRef();
t.Something = "Bar";
}
}
public class TestRef
{
private string s;
public string Something
{
get {return s;}
set { s = value; }
}
}
Since TestRef is a class (which are reference objects), you can change the contents inside t without passing it as a ref. However, if you pass t as a ref, TestRef can change what the original t refers to. i.e. make it point to a different object.
With ref you can write:
static public void DoSomething(ref TestRef t)
{
t = new TestRef();
}
And t will be changed after the method has completed.
Think of variables (e.g. foo) of reference types (e.g. List<T>) as holding object identifiers of the form "Object #24601". Suppose the statement foo = new List<int> {1,5,7,9}; causes foo to hold "Object #24601" (a list with four items). Then calling foo.Length will ask Object #24601 for its length, and it will respond 4, so foo.Length will equal 4.
If foo is passed to a method without using ref, that method might make changes to Object #24601. As a consequence of such changes, foo.Length might no longer equal 4. The method itself, however, will be unable to change foo, which will continue to hold "Object #24601".
Passing foo as a ref parameter will allow the called method to make changes not just to Object #24601, but also to foo itself. The method might create a new Object #8675309 and store a reference to that in foo. If it does so, foo would no longer hold "Object #24601", but instead "Object #8675309".
In practice, reference-type variables don't hold strings of the form "Object #8675309"; they don't even hold anything that can be meaningfully converted into a number. Even though each reference-type variable will hold some bit pattern, there is no fixed relationship between the bit patterns stored in such variables and the objects they identify. There is no way code could extract information from an object or a reference to it, and later determine whether another reference identified the same object, unless the code either held or knew of a reference that identified the original object.
This is like passing a pointer to a pointer in C. In .NET this will allow you to change what the original T refers to, personally though I think if you are doing that in .NET you have probably got a design issue!
By using the ref keyword with reference types you are effectively passing a reference to the reference. In many ways it's the same as using the out keyword but with the minor difference that there's no guarantee that the method will actually assign anything to the ref'ed parameter.
ref mimics (or behaves) as a global area just for two scopes:
Caller
Callee.
If you're passing a value, however, things are different. You can force a value to be passed by reference. This allows you to pass an integer to a method, for example, and have the method modify the integer on your behalf.
I offten (like at the moment) come to the point to write c# (or vb.net) code like this:
someObject.field_1 = doSomething(
anotherObject_1.propertyA,
anotherObject_1.propertyB);
someObject.field_2 = doSomething(
anotherObject_2.propertyA,
anotherObject_2.propertyB);
// some more field in same schema.
someObject.field_X = doSomething(
anotherObject_X.propertyA,
anotherObject_X.propertyB);
Edit: anotherObject_1 .. anotherObject_X have same typ; someObject and anotherObject have normaly not the same typ.
The Problem is the expandability and maintainability. New field brings me to write nearly same code with only little differences in object naming.
With encapsulate the logic in doSomething(..) I avoid logic redundancy, but the calling redundancy is still annoying.
Is there a way (for example a pattern or a .Net (4.0) language-construct) to avoid this?
You can encapsulate set operation into different method
void SetField(ref int field, object anotherObjectX)
{
field = doSmth(anotherObjectX...);
}
SetField(ref object.field1, anotherObject1);
SetField(ref object.field2, anotherObject2);
SetField(ref object.field3, anotherObject3);
but you still need to add the new line for the each new field
You can use Reflection to reduce code duplication/repetition. If know that your target property would always be called "propertyA" and "propertyB", you can easily use reflection and get/set their value as needed. You can pass in your object as well, and manipulate it there with reflection also.
For example, you can write something like this (note: syntax not fully checked):
public someReturnType DoSomething(object myObject)
{
if (null == myObject)
{
throw new ArgumentNullException("myObject");
}
var propertyA = myObject.GetType().GetProperty("propertyA");
if (null == propertyA)
{
//this object doesn't have any property called "propertyA".
//throw some error if needed
}
var value = propertyA.GetValue(myObject); //You will need to cast as proper expected type
// You can retrieve propertyB similarly by searching for it through GetProperty call.
// Once you have both A and B,
// you can work with values and return your output as needed.
return something;
}
So I have a simple method called Invert:
public static void Invert(this bool value)
{
value = !value;
}
It is inside of a static class in a .dll file. Now when I go to a new Winforms project, I add the .dll as a reference and everything is good so far. Now when I do this:
bool test = true;
test.Invert();
I get no errors, but when I do:
MessageBox.Show(test.ToString());
It outputs true, as if nothing has changed. I am not sure if it because of what I am doing in the method or something else. But if I go:
MessageBox.Show((!test).ToString());
It outputs false.
Thanks.
That's working correctly. Because bool is a value type, it's passed as a value and the original variable (test) is not ever being changed.
Instead you should do something like:
public static bool Invert(this bool value)
{
return !value;
}
However, creating a method that does what the language does itself is a bit of a waste of time.
I don't think extension methods will let you take a this parameter by reference, so you would have to use a regular static method, and call it the long way:
public static bool Invert(ref bool value) { value = !value; }
BooleanHelpers.Invert(ref test);
In the end, it's going to be a lot cleaner and easier (not to mention more obvious to other developers) to just do it this way:
test = !test;
Your extension method takes in the bool by value, not by reference. The body of the method is changing the local copy of the bool, not the original value owned by the caller.
bool is a value type, and you aren't passing it by reference. You need to assign the result of Invert to another or the same variable for it to persist.
I've been using delegates for many years, and haven't really given them much thought.
But I recently got egg on my face by assuming that delegates stored a this reference when referencing a class method.
The below example illustrates the gap in my understanding.
public class SomeClass
{
public SomeClass(int someProperty)
{
SomeProperty = someProperty;
}
public int SomeProperty
{
get;
set;
}
// Throw in a Member field into the mix
public int ClassAdd(int x, int y)
{
return x + y + SomeProperty;
}
}
public static class SomeStaticClass
{
public static int StaticAdd(int x, int y)
{
return x + y;
}
}
Why is it that I can add both static and instance subscribers?
class TestClass
{
delegate int myAddDelegate(int x, int y);
private void UseDelegates()
{
myAddDelegate algorithm;
algorithm = new SomeClass(3).ClassAdd;
// Surprised that I could add static methods to my delegate?
algorithm += SomeStaticClass.StaticAdd;
// I'm fine with just one of the results being returned.
int answer = algorithm(5, 10);
}
}
What is actually going on? ;)
If you create a delegate referring to an instance method, it will capture this (or the relevant reference) in the field backing the Target property of the delegate. If you create a delegate referring to a static method, the Target will be null. Logically there's no need to have an instance if you're using a static method.
As one added complications, you can capture extension methods as if they were instance methods on the extended type:
static class Extensions
{
public static void Foo(this string x)
{
Console.WriteLine("Calling Foo on " + x);
}
}
class Test
{
static void Main()
{
Action action = "text".Foo;
Console.WriteLine(action.Target); // Prints "text"
}
}
As for why you can do all of this: because it's useful, and there's no reason not to allow you to do it :)
There are no static functions in C#, they are actually static methods (so there are static and instance methods). Every delegate basically is pointer to method and this pointer on which the method will be executed, it is Target property of delegate. In case of static method it will be null. Since delegate carry reference to objects it can cause memory leaks if you forget to unsubscribe.
The beauty of delegates is that they just work, for both static and instance methods. If you assign a static method to a delegate, the static method is simply used as-is, since it doesn't need any non-static context to work. For instance methods, a reference to the instance is stored along the method pointer, so that the necessary context (the this reference) is available when the method is called. This means that when you assign an instance method to a delegate, you must also provide an instance - either by specifying it explicitly, or by assigning to the delegate from inside an instance context.
Most of the time, this 'just works', and you don't need to think about anything. There is one caveat though: If you assign an instance method to a delegate, you create another reference to the instance, and as long as the method remains assigned to the delegate (or subscribed to an event), there will also be a reference to the instance, so the GC will never collect it. This is why you should always unsubscribe from all events when cleaning up after yourself.