How C# compiler interpret objects that specified by var keyword? When do we must use this keyword?
+1
A:
If you mean the "var" keyword used in variable declaration then there is no such thing as "var type". This "var" is interpreted (at compile time) as type inferred from expression that is assigned to the variable.
PanJanek
2010-02-18 12:32:21
+4
A:
Beginning in Visual C# 3.0, variables that are declared at method scope can have an implicit type var. An implicitly typed local variable is strongly typed just as if you had declared the type yourself, but the compiler determines the type.
o.k.w
2010-02-18 12:32:29
+6
A:
There are times when you need to use var, for example, when using an anonymous type, such as in a LINQ query:
var results = context.People.Select(p => new {p.PersonID, p.Name});
See the new{} line in there? That's returning a class which is being generated at compile-time. Since this class has no name, the only way you can refer to it in your code is by using "var". This cuts down on you having to create tons and tons of special-purpose classes just for LINQ resultsets.
Under the hood, whether you use var just as a shorthand for another type, or if using an anonymous type, you are still doing static, compile-time type checking. Dynamic types are not being used. The compiler literally figures out what the type should be when you compile, so a program like:
var i = 12;
i = i + "foo!";
won't compile.
Dave Markle
2010-02-18 12:37:19
why don't we use object type for anonymous type?
masoud ramezani
2010-02-18 12:42:42
+1 for mentioning its proper use - too many people are getting lazy and using it all over the place.
slugster
2010-02-18 12:47:29
@slugster - to write off the use of var as laziness is really laziness on your part. Presumably you've never spent much time using languages such as Haskell or F# that make extensive use of type inference, and you've never tried writing C# using var wherever possible? Many who have find use of var everywhere much more readable, so it's a positive choice after *not being lazy* and *evaluating the options*.
Greg Beech
2010-02-18 12:51:27
+1 for Greg for getting it. -1 to slugster for not even trying
Rune FS
2010-02-18 13:05:12
@masoud: you most certainly could use object. In fact, I use object with anonymous types when I want to return an anonymous type via a web service for an ajax call. The JSon serializer then figures it all out. (Try it, it's awesome). But using object in general in place of var would be bad, because you'd lose all compile time type checking and intellisense. And you'd have to cast it just about everywhere to base interfaces to get anything done.
Dave Markle
2010-02-18 13:13:56
Maybe I am old-fashioned, and I'll admit I haven't had much practice at 'var everywhere' but presently I find it far LESS readable. I DO appreciate the necessity of 'var', and can see why 'var eveywhere' would make you think about 'behaviour' rather than 'types' - and certainly about nice short methods!!! So in terms of the WRITING of code, I can see its advantages. BUT I can't deny that I personally find it much slower to READ the code.
kpollock
2010-02-18 13:28:05
@slugster - nothing to do with laziness. `var myList = new List<Action<Foo>>();` is much cleaner and more readable than `List<Action<Foo>> myList = new List<Action<Foo>>();` It removes redundancy, it's less code and it compiles to the same IL.
Winston Smith
2010-02-18 14:21:30
Bwahahahaha, all the haters come out of the closet :) I have never used Haskell or F#, but i have done my time using other loosely typed languages and i think a lot of people carry over bad habits from those languages. People have to realise that generic use of 'var' is a religious argument (like VB.Net vs C# arguments), there are people for and against, and neither camp is totally right or wrong. I'm a purist, but at least i know that people will disagree with me, and i respect their right to disagree.
slugster
2010-02-18 22:14:00
+2
A:
In Var declaration,
Compiler infer the type from the assigned value
on
var a = 100; // compiler assumes a is a integer
var b = "test"; // compiler assumes b is a string
Why do we need them (why cant we use objects directly)
Because object doesnt enforce type safety
object objtest = 1;
objtest = "test";
this works fine.
But var enforces type safety
var a = 100;
a= "test";
this doesnt compile, and will give the compile time error.
Where we can use them
- Linq queries returning Anonymous types
- And anywhere you want to define type safe variables (simplicity) . instead of writing something like this.
.
RootClass rt = new RootClass ();
List<RootClass > rt = new List<RootClass >();
you can write like this
var aaaaaa = new RootClass ();
var ls = new List<RootClass>();
Cheers
Ramesh Vel
2010-02-18 12:57:50