Reputation: 10422
I am reading this article to understand difference between var and IEnumerable. Author wrote four points like following
point no. 3 & 4 is not clear to me. Please help to understand these point with examples
Upvotes: 1
Views: 1349
Reputation: 81179
If one says var MyList = SomeStringCollection.ToList()
; MyEnumerator = MyList.GetEnumerator();, then the type of
MyListwill be
List, and the type of
MyEnumeratorwill be
List.Enumerator, which is a *value type* that implements
IEnumerator, and will thus exhibit *value semantics*. If the type of
MyListhad been
IEnumerable, the return type of
MyList.GetEnumerator()would have been
IEnumerator`, which has reference semantics.
This difference could be important if e.g. one had a method which read five items from an IEnumerator<String>
. If one calls such a method multiple times with a variable of type IEnumerator<String>
, each call will read the next five items from the enumeration. By contrast, if one calls such a method multiple times with a value type like List<String>.Enumerator
, each call will copy the enumeration state to a new heap object which implements IEnumerator<T>
, pass that object to the method (which will read five items through it), and then abandon that object and its associated space (leaving the enumeration state associated with the original variable unaffected).
Note that in probably 99% of cases, either value semantics or reference semantics would be equally acceptable in an enumerator; in the majority of those, value semantics would make code run faster, and only very rarely would it make code run meaningfully slower. Further, there are some cases where knowing that an enumerator will behave as a value type could be semantically useful (e.g. if one wanted to be able to repeatedly re-enumerate part of a collection). On the other hand, it's probably a good idea for code which uses implementations of IEnumerator<T>
to be aware of what kind of implementation they may be using.
Upvotes: 1
Reputation: 45083
Everything is wrong here, so briefly at least:
var
doesn't change that;IEnumerable
generally just does represent an in-memory collection (it doesn't have to, mind, as it's only a contract for collections toi adhere to, regardless of their ultimate storage) and the idea is largely juxtaposed to the rest of this question;A note on usage of var
, though, to give a broader set of notions: using var
is generally only a good idea when the resultant type is evident based on the current statement - I don't really understand Darren's reasoning or how that would ever be useful, but consider the following:
var results0 = new List<string>(); // assignment type is obvious
var results1 = something.GetResult(); // read must investigate to know
Upvotes: 6
Reputation: 70728
var
is a contextual keyword that implicitly types a variable. When you use IEnumerable<T>
you are explicitly stating the type to be defined, were as var will use type inference.
It doesn't really make a difference which one you use, more of a coding style IMO, I personally use var
when returning something from a collection using LINQ
rather than IEnumerable<T>
or IQueryable<T>
.
var value5 = list.Where(i => i == 5).ToList();
IEnumerable<int> value5 = list.Where(i => i == 5).ToList();
Both will generate the same output.
With regards to point 3 and 4. I don't believe that IEnumerable is any more beneficial for in memory collections at all. Behind the scenes the CLR
will infer the variables type (When using var) at runtime, most likely to IEnumerable<T>
.
Upvotes: 3
Reputation: 1601
var
is just an implicitly typed local variable. You just let the compiler determine the type.
var i = 10; // Implicitly typed
int j = 10; // Explicitly typed
It is also super handy when working with anonymous types, eg.
var anon = new { Foo = "Bar" };
Console.WriteLine(anon.Foo); // Puts "Bar" on console.
Upvotes: 1